I'm afraid I got confused. It seems the confusion stems from the use of the
term poll. I was referring to the use described in
http://en.wikipedia.org/wiki/Polling_%28computer_science%29 , ie something
like : check the status of the files by looking at their timestamps, wait a
fixed timeout, and check again (which is terrible, I hope you agree). "poll"
and "select" system calls look like what the wiki page calls
interrupt-driven IO (which does have the qualities I described in my
previous post).

I was not aware of these (shame on me). They mean inotify has no relevance
to the action of watching for changes in a file, where poll and select do
the trick perfectly well.
2009/9/12 Eli Zaretskii <eliz@gnu.org>

> > Date: Sat, 12 Sep 2009 19:26:14 +0200
> > From: Antoine Levitt <antoine.levitt@gmail.com>
> > Cc: lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org
> >
> > > > Date: Sat, 12 Sep 2009 18:36:47 +0200
> > > > From: Antoine Levitt <antoine.levitt@gmail.com>
> > > > Cc: lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org
> > > >
> > > > 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.
>