emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs inotify support?


From: Antoine Levitt
Subject: Re: Emacs inotify support?
Date: Sat, 12 Sep 2009 22:04:49 +0200

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 <address@hidden>
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]