Rate limit needed (Was: Re: [PATCH] fix #47996)

[Waldo Bastian]

>On Thursday 07 November 2002 20:57, Roger Larsson wrote:
>>  On Thursday 07 November 2002 18.04, David Faure wrote:
>>  > On Thursday 07 November 2002 18:09, Josef Weidendorfer wrote:
>>  > > I once suggested a work around if the copying is controlled by KDE:
>>  > > Do it in an unwatched directory (e.g. in directory ".hidden/" of the
>>
>>  target
>>
>>  > > dir) and then do a move.
>>  >
>>  > Users don't want that. It would mean that they can't "watch the file grow
>>  > as it is being downloaded". It would all appear to be broken.
>>
>>  ...
>>  This could be done in this case too. When there are few events. Report them
>>  all. If there are many collect and merge before reporting.
>
>Good idea.
>Meassuring the rate influences the event merging and delay...
>
>>  Another trick used in Real Time systems is to lower the priority of the
>>  event generator. Then it can not produce more events than can be processed.
>>
>>  This is something to try in this case - try to run FAM with a really low
>>  nice! What happens?
>
>But FAM is not the generator. The generator is the kernel itself (in case of
>DNOTIFY).
>
>If DNOTIFY is used in the KDE app itself: Want you to renice each KDE app?

A DNOTIFY event triggers a stat-rescan in KDirWatcher, the rate of 
the rescans can be limited by delaying it a bit. This already 
happens, we wait 200ms before doing the rescan. So when KDirWatch 
uses DNOTIFY the event rate is limited to at most 5 events / sec. FAM 
should do the same ;-)

Cheers,
Waldo