Re: [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes

[nf <nf2 scheinwelt at>]

On Tue, 2004-06-01 at 12:06, Alexander Larsson wrote:
> On Mon, 2004-05-31 at 20:13, nf wrote:
> > I have posted this to the kernel list. Might be interesting for the nautilus 
> > developers as well. Perhaps this could be used by "fam" instead of dnotify. 
> > Cause i don't see any problems with delivering events from a "polling" mechanism.
> > But i don't know if we really need fam in this case, or rather use it from 
> > gnome-vfs directly.
> 
> Not that this might not be a good idea, but your measurements are a bit
> skewed. I'm pretty sure that events could be done in a way that uses
> less resources (and doesn't block unmount)

You must be joking. ;-) Of course there might be the perfect
notification mechanism which solves every problem. But do we really have
to wait for kernel 2.8 or later to have a linux desktop which actually
works? It's almost ten years since Billie brought us a working Windows
95 which didn't lock up CDs - and the linux desktop is still a joke
because nobody fixes those basic problems in a pragmatic and simple way.

The fact is: There is no notification mechanism which works properly at
the moment. And it won't happen soon. It's a very complex task which
needs lots of testing. You need to touch every corner of the kernel.
Just search the kernel archives for "dnotify". There are endless
discussions, but no solution which is yet satisfying.

In the meanwhile - while waiting for the most excellent solution -
nobody removes dnotify. Seems to be a kind of deadlock situation.

> , and what you're measuring is
> the worst-case for a notify approach. 

Of course it's a worst case, but taking 90% of CPU time is just crazy. 

> The worst-case for nonotify is the
> cpu usage when the system should be idle, 

This idle activity is negligable. One stat-call takes about 2
microseconds. Thus, if you watch 500 directories with "nonotify" you'll
need about 1 millisecond. This is 0.1% of your CPU time if you poll
every second.

> and the fact that to get the
> "dnotify" effect of files appearing in the file manager when they are
> created you have to poll very often.

Why? Polling happens in a fixed interval - that's the big advantage: The
impact is predictable. (Re)reading a directory like /usr/bin (2400
entries) takes about two milliseconds on my system (=0.2% CPU time if
you do it every second). So if there is really massive file copying
going on on a slow computer - changing every directory you are
monitoring - maybe you will need 5% of CPU time for directory change
detection. That's nothing.

Norbert