Re: mnotify: mixing nonotify & simple mount watching (Was: Re: [RFC/PATCH] Nonotify...)

[John McCutchan <ttb tentacle dhs org>]

On Sun, 2004-08-15 at 07:14, nf wrote:
> On Sun, 2004-08-15 at 02:20, John McCutchan wrote:
> >  It's cool and i hope you
> > > can convince the kernel maintainers ... although i still think
> > > generating events is a bit of an overkill, because you need to aggregate
> > > them on the client side with timers anyway...
> > 
> > inotify 0.5 is very old. You should try a newer version (I will put up a
> > new patch for linux-2.6.8.1 soon). Checking for events is very cheap and
> > you don't need timers, just use select() like all unix apps.
> > 
> 
> No i meant: You need to aggregate events with timers in the client to
> avoid GUI-flickering and taking too much CPU-power by dealing with each
> event.


Ahh, now I see your point. With inotify the gui probably does need to
'buffer' events for a bit so they aren't updating on every event. This
behavior does not require a timer. 

When using inotify to watch a directory you can get events like
IN_CREATE with 'abc.txt' as the argument to the event. That requires
much less processing then dcontents_mtime just telling you a directory
has been changed. Inotify tells you the filename that was created /
deleted.

> 
> > I don't see the point in having dcontents_mtime, inotify will tell you 
> > when an event happens and as long as the app and system behave properly
> > the queue should never over flow. dcontents_mtime just seems like kludge
> > around an program bug. If an app lets the queue over flow, it might as
> > well re-stat everything. 
> > 
> 
> I don't get it: Why is it a bug in the application if it doesn't get
> enough CPU-time to read all the events? As far as i understand inotify,
> there is simply NO guarantee that you receive all events. It's just
> "luck".

It's not luck but the kernel makes no guarantees that an app will get
all the events. The kernel just can't afford to spend the resources
trying to guarantee that all events are delivered to the client.
This is simply a luxury for the client. If you look at other operating
systems that deliver events such as these to user space they also don't
make any guarantee about the app getting all events.

In reality I don't think this will be much of an issue, in the kernel
we can make each /dev/inotify event queue arbitrarily long, and getting
events from the dev is VERY cheap. 

In my tests the only time I would get queue overflow is if I was
watching a directory for all files that get read. So every read() call
was sending an event.


John