Re: [gamin] New inotify backend checked in
- From: John McCutchan <ttb tentacle dhs org>
- To: veillard redhat com
- Cc: gamin-list gnome org
- Subject: Re: [gamin] New inotify backend checked in
- Date: Wed, 03 Aug 2005 12:20:55 -0400
On Wed, 2005-08-03 at 11:15 -0400, Daniel Veillard wrote:
> On Wed, Aug 03, 2005 at 09:33:06AM -0400, John McCutchan wrote:
> > > We should make the flood tests check for the deactivation of the
> > > kernel monitoring, this could be different for inotify but this should
> > > still be done. I need to double check dnotify15.py for analysis.
> >
> > Well, the inotify backend will never deactivate kernel monitoring.
>
> I really disagree with this.
I think you should do some performance testing with the inotify backend
before you come to any conclusion.
>
> > Because I don't want to have to maintain the stat() trees. There are
>
> The kernel has no flow control.
The kernel does provide flow control that works REALLY well for the
standard 'download iso' test case. I watched my home directory, and dd
if=/dev/zero of=testfile . The kernel only sent me 1-7 events every
second. Compare that with the countless events dnotify would send in
that same case. Also, handling events coming from inotify is practically
free. It's just a read from the file descriptor. Performance is really
good with this new backend.
And with my planned per-connection event queue, we can drop the number
of events even delivered to applications without resorting to disabling
kernel monitoring.
> It then must be implemented at the user level.
> It is not acceptable to argue about a specific problem in Dnotify support
> to just cancel this fundamental property. inotify would not need to
> maintain a tree of stat() info but one per cancleeled kernel monitor.
Keeping a stat() tree for each cancelled kernel monitor isn't as easy as
it sounds. That is a very racey operation. It would be easy to miss
events in between your last inotify event and the scan of the directory.
> You
> are throwing the baby with the bath water, this is just wrong. If you drop
> flow control, then gamin provides absolutely no added benefice on top of
> inotify and I don't see the point of even maintaining a back-end for it !
>
Sure it does. It provides multiplexing of watched paths, kernel
resources can be saved by having gamin multiplex to all the apps
interested in watching $HOME, etc.. Gamin also provides an interface
that all applications already use.
--
John McCutchan <ttb tentacle dhs org>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]