Re: mnotify: mixing nonotify & simple mount watching (Was: Re: [RFC/PATCH] Nonotify...)
- From: nf <nf2 scheinwelt at>
- To: John McCutchan <ttb tentacle dhs org>
- Cc: Danny Milosavljevic <danny milo gmx net>, Nautilus mailing <nautilus-list gnome org>, Josef Weidendorfer <Josef Weidendorfer gmx de>
- Subject: Re: mnotify: mixing nonotify & simple mount watching (Was: Re: [RFC/PATCH] Nonotify...)
- Date: Sun, 15 Aug 2004 13:14:21 +0200
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.
> 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".
Norbert
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]