Solution for KDirWatch flooding problem with Linux?

[Josef Weidendorfer]

Hi,

I just found out about AEM (http://aem.sourceforge.net), and I wrote the 
author a question regarding KDE's signal flooding problem with DNOTIFY.
Below is his answer. It seems that the aem_fd module of AEM could be
a perfect replacement for DNOTIFY, perhaps even in 2.4.x already.

I don't have much time for this at the moment, but perhaps somebody
has the motivation to add AEM support to KDirWatch, or even better,
write a patch for FAM and sent it to the SGI FAM people?

Oh, and there's another reason for AEM I forgot below: Hopefully it makes
unmounting of watched directories possible.

Josef

==================

Question regarding AEM
Von: Frederic Rossi <frederic.rossi at ericsson.com>
An: Josef Weidendorfer <Josef.Weidendorfer at gmx.de>

Josef Weidendorfer wrote:
> Hi,
> 
> I just found out about AEM when reading the last Linux Kernel Traffic.
> 
> I noted the aem-fd module. And this reminded me of a problem we have in KDE:
> For automatic updates of file manager views, we use as notification 
mechanism 
> mainly DNOTIFY on LINUX now (abstracted behind the FAM daemon, which usually 
> is using DNOTIFY for local files).
> 
> Our big problem is that 
> (1) DNOTIFY sometimes is flooding ourselve with events (using realtime 
> signals),
> (2) only a limited number of directories can be watched because each needs 
an 
> open file descriptor in the fam daemon.
> 
> It seems to me that aem-fd would solve (2). For (1), we need a 
> delaying/merging capability already in the kernel to reduce 
context-switches, 
> but there's no patch around for something like this.

AEM already provides support for event coalescence and some light control on
events (like stop/start) at the application level. Event coalescence is 
actually event specific and must be implemented by modules writers. For 
example it prevents from receiving an event each time a tcp/ip fragment is 
received. But this is at the architecture level.

> The general solution using AEM would be something like a event frequency 
> limiter. It seems that this even could make sense for all kind of events.
> Is something like this feasable with the current architecture?

Absolutly. This is something I though of but in the context of security.
There is no technical problems behind this. Instead I prefer to wait until I 
receive comments from people on what kind of functionalities they need.

> 
> Do you think that AEM has a chance to merge with the standard linux source 
> base? 

Yes. Because it solves problems that are difficult to solve with other 
mechanisms.

> 
> Thanks for any response,

Thanks for your feedback,

> Josef

Frederic