Re: Directory-change notification (was Re: Desktop)
- From: Aaron Lehmann <aaronl vitelus com>
- To: "Bruce W. Bigby" <bbigby rochester rr com>
- cc: Owen Taylor <otaylor redhat com>, Roberto Zunino <zunino cli di unipi it>, Loban Rahman <loban enigma caltech edu>, gnome-devel-list gnome org, recipient list not shown: ;
- Subject: Re: Directory-change notification (was Re: Desktop)
- Date: Mon, 14 Feb 2000 09:59:41 +0000 (GMT)
I see a lot of kernel space discussion going on. By "the kernel", I think
you mean "the Linux kernel". Please keep in mind that Linux is not the
only Unixlike OS and not everyone uses it. Last time I checked gnome ran
on other platforms and I think that is not something which would be good
On Sat, 12 Feb 2000, Bruce W. Bigby wrote:
> Owen Taylor wrote:
> > Roberto Zunino <firstname.lastname@example.org> 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
> > 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 email@example.com with "unsubscribe"
> > as the Subject.
> Bruce W. Bigby
> Do for others what you would want others to do for you.
> To unsubscribe: mail firstname.lastname@example.org with "unsubscribe"
> as the Subject.
] [Thread Prev