[gamin] Re: [RFC][PATCH] inotify 0.9
- From: Robert Love <rml novell com>
- To: John McCutchan <ttb tentacle dhs org>
- Cc: akpm osdl org, gamin-list gnome org, nautilus-list gnome org, viro parcelfarce linux theplanet co uk, linux-kernel vger kernel org, iggy gentoo org
- Subject: [gamin] Re: [RFC][PATCH] inotify 0.9
- Date: Wed, 15 Sep 2004 14:00:09 -0400
On Wed, 2004-09-15 at 11:52 -0400, John McCutchan wrote:
> I am interested in getting inotify included in the mm tree.
>
> Inotify is designed as a replacement for dnotify. The key difference's
> are that inotify does not require the file to be opened to watch it,
> when you are watching something with inotify it can go away (if path
> is unmounted) and you will be sent an event telling you it is gone and
> events are delivered over a fd not by using signals.
I want to expand on why dnotify is awful and why inotify is a great
replacement, because dnotify's limitations are really showing up on
modern desktop systems.
Some technical issues with dnotify and why inotify solves the problem:
- dnotify requires one fd per watched directory. this results
in a lot of file descriptors if you are trying to do anything
creative. inotify solves this by only having one open file
descriptor.
- with dnotify, you open the fd on the directory to watch, which
pins the directory. this makes unmounting the backing
filesystem impossible and means using dnotify on removable
devices is nontrivial. This is a problem with desktop systems.
Not only does inotify solve this problem (by not requiring an
open of each watched directory), but it even sends an "unmount"
event when the watched directory is unmounted.
- Using dnotify is, uh, interesting. I mean, fcntl(2) and
SIGIO? You end up needing to use real-time signals. Gross
gross gross. This does not working well with modern event-
driven applications that use mainloops. You end up needing a
complicated daemon like FAM. We don't want FAM, and in fact we
should not even need a daemon (although we might want one).
Conversely, inotify is trivial to use and integrates well and is
select()-able.
I have been going over the code for awhile now, and it looks good. I
would really like to hear Al's opinion so we can move on fixing any
possible issues that he has.
Best,
Robert Love
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]