Re: Directory-change notification (was Re: Desktop)

[Roberto Zunino <zunino cli di unipi it>]

On 12 Feb 2000, Owen Taylor wrote:

> Have you ever got any feedback on this patch from the kernel people?

My patch is a 2-day hack (and my first hack to the kernel): I'm sure that
it's not perfect and maybe it could have races and similar. To be honest,
I never proposed it for inclusion to the linux kernel.

> I discussed this with Alan Cox and Stephen Tweedie at one point, and
> their feeling was that directory-change notification would not
> work well in the framework of select/poll, because it indicates a
> event, rather than a condition; this has a bunch of consequences,
> for instance:

Well, since I was thinking about a filemanager I thought that the app had
to be notified of the "not-up-to-date" condition.

[snip]
> One possibility for a solution would be to rephrase the problem
> as "wake me when the directory has changed since last opened" (or
> since something else) rather than "wake me when the directory has 
> changed".

That is exactly the paradigm behind my patch. The patch uses poll() even
to _mark_ the moment of updating: of course this is completely crazy and I
did it to avoid messing with other syscalls. In a "official" way there
must be a different way to mark time.
The app should do hysteresis, anyway...

[snip: RT signals & sys daemon]
> A possibility that occurs to me for dealing with that problem of
> message-queue overflows is to have a user-space daemon that is
> notified by the kernel via RT signals, has the proper fallbacks when
> overflows occur, and that then talks to the various processes using
> standard Unix-domain sockets. This solution also has the advantage
> of being easily emulated by periodic checking on systems without
> the appropriate kernel feature.  

To say the truth, I prefer the poll() approach but please note that I tend
to mentally put all the "async/scheduling/non-blocking/notifying" stuff
into the kernel.

The poll() can be integrated directly into the app (say into glib).
The daemon OTOH could be a more adaptable solution.

Both approaches have portability issues (maybe the daemon is better in
this case).

Network file systems should be considered too...

Regards,
Zun.