Re: Emacs inotify support?

[Eli Zaretskii]

> Date: Sat, 12 Sep 2009 19:26:14 +0200
> From: Antoine Levitt <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> > > Date: Sat, 12 Sep 2009 18:36:47 +0200
> > > From: Antoine Levitt <address@hidden>
> > > Cc: address@hidden, address@hidden, address@hidden
> > >
> > > If possible, polling should be avoided, though.
> >
> > Why?
> 
> Well, I don't know much about file systems, but isn't it always better
> to be notified than to poll ?

But (AFAIU) inotify works by giving the application a file descriptor
that the application needs to pass to `select' or `poll' in order to
get notifications.  This is exactly the kind of ``polling'' Emacs does
with any external event (except for signals).

So we are up for polling anyway.

> First, having a notification system
> means it's instantaneous. Second, I'd imagine querying the state of a
> file has a cost (especially if it can't be cached and needs a real
> access to the hard drive). Third, it'd avoid a waste of CPU resources
> (which may be important for power consumption, since, from what I
> understood, the more a program has fixed timers, the more it wakes the
> CPU from sleep). Fourth, being notified is more high-level, since the
> notification itself can be implemented by polling. One could imagine a
> notification API where the backend would use inotify if available,
> polling if not.

You seem to be thinking of some signal-like mechanism.  But that's not
how these notifications work (nor do I think it's a good idea for them
to work like that in Emacs, where interrupting code at an arbitrary
moment is not a good idea).

As for wasting CPU time, system calls like `select' and `poll' don't
waste them too much.