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

["Bruce W. Bigby" <bbigby rochester rr com>]

Owen Taylor wrote:
> 
> Roberto Zunino <zunino@cli.di.unipi.it> writes:
> 
> > On Fri, 11 Feb 2000, Loban Rahman wrote:
> >
> > >
> > > Is the .gnome-desktop directory periodically rescanned, or only when
> > > something is dragged onto it? It ought to be the latter in my opinion
> >
> > You mean the former (periodical rescan)?
> >
> > > because the contents of .gnoem-desktop could be changed by not dragging
> > > something into it (e.g. copying somthing directly into the folder, or
> > > maybe a link becomes invalid from valid or vice versa, etc), and it ought
> > > to reflect the change.
> >
> > This applies to directories as well.
> >
> > The problem is that the only portable way to do this is to continuously
> > recan the directory (every 2 sec. for example).
> > BTW, this is how Windows does it. I have been told that OS/2 does the same
> > thing, and I'd bet the Mac does too.
> >
> > Rescanning isn't the "Right Way" to go IMHO and I believe most programmers
> > share my view. This is because rescanning shouldn't be necessary from a
> > "theoretical" point of view and beacuse it can be expensive: consider a
> > gmc/nautilus/etc. window displaying /usr/bin, /dev or another dir with
> > more than 1000 files. Consider 10 windows displaying 10 "big" folders,
> > too. And what about NFS ?
> >
> > <disclaimer>
> > If you had ever looked at my home page
> > (http://www.cli.di.unipi.it/~zunino) you'd have expected a similar
> > answer from me. If I liked rescanning/polling I hadn't written that ugly
> > patch to linux 2.2.13 that lets you poll() a directory in order to wait
> > for changes :-)
> > </disclaimer>
> 
> Have you ever got any feedback on this patch from the kernel people?
> 
> 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:
> 
>  - the operation can't be simply restarted
>  - there is no way of making the operation reliable. If the
>    process isn't sleeping when the directory changes, it won't
>    learn about it. There is a race condition between
>    checking if the directory changed and entering the poll.
> 
> 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".
> 
> Another other possibility would be to use a mechanism more suitable
> for "messages", such as POSIX real-time signals. The problem with this
> is that POSIX RT signals have a nasty API, and in fact, systems of
> messages from the kernel will inevitably have a nasty API, simply
> because you can't allocate an arbitrary-sized queue in the kernel and
> have to to deal with the possibility of overflow.
> 
> 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.
> 

This sounds like a very practical solution so I agree with you. Go to
it!

> Regards,
>                                         Owen
> 
> [ P.S. - if somebody figures out a decent way to do this and
>   gets a patch into the kernel, GUI folks will be in their debt
>   forever. ]
> 
> --
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.

-- 
Bruce W. Bigby
http://home.rochester.rr.com/bigbyofrocny
Do for others what you would want others to do for you.