> Date: Sat, 12 Sep 2009 19:26:14 +0200
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.