Re: [RFC/PATCH] inotify -- a dnotify replacement

[John McCutchan]

On Mon, 2004-05-10 at 22:47, Chris Wedgwood wrote:
> On Mon, May 10, 2004 at 06:17:40PM -0400, John McCutchan wrote:
> 
> > According to everyone who uses dnotify it is.
> 
> I don't buy that.  I have used dnotify and signals where not an issue.
> Why is this an issue for others?
> 

Signals cause a big performance penalty when you are receiving a lot of
them. Signals interrupt your program, switch the signal handler and then
restarts your program. And signals in multi-threaded programs is a pain
as well. Signals just are not suitable for receiving lots of messages
quickly.

> > > 3) dnotify cannot easily watch changes for a directory hierarchy
> 
> > People don't seem to really care about this one. Alexander Larsson
> > has said he doesn't care about it. It might be nice to add in the
> > future.
> 
> I don't know who that is and why it matters.
> 
> Without being able to watch a hierarchy, I'm not sure inotify buys
> anything that we can't get from dnotify right now though.  It's also
> more complex.

Inotify will support watching a hierarchy. The reason it was not
implemented yet is because the one app that I really care about is
nautilus and the maintainer of it says he doesn't care. 

The big feature that inotify is trying to provide is not having to keep
a file open (So that unmounting is not affected). I asked for some
guidance from people more familiar with the kernel so that I can
implement this feature, it requires changes made to the inode cache, and
how unmounting is done.

> 
> > The idea is to encourage use of a user-space daemon that will
> > multiplex all requests, so if 5 people want to watch /somedir the
> > daemon will only use one watcher in the kernel. The number might be
> > too low, but its easily upped.
> 
> If you are to use a daemon for this, why no use dnotify?

Because of the problems that dnotify has, as well if people would prefer
to just use a direct interface, those #defines can be upped. Its very
easy to play with the limits on the number of watchers. I am not sure
what kind of impact this will have on the kernel resources, so I wanted
to keep it small.

John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/