From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.devel Subject: Re: Emacs inotify support? Date: Sat, 12 Sep 2009 22:04:49 +0200 Message-ID: <6fa54e4e0909121304u1ddc5b78tc7c9e1f5c756aabf@mail.gmail.com> References: <6fa54e4e0909111554g4165418albbdffc142b3b52ee@mail.gmail.com> <83tyz8z3sl.fsf@gnu.org> <6fa54e4e0909120936s24634600sf00a818aabd308ce@mail.gmail.com> <83r5ucyuf0.fsf@gnu.org> <6fa54e4e0909121026t797ee747yc2ac395314c3cc40@mail.gmail.com> <83my50ymj5.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016364173ade84b22047366f10a X-Trace: ger.gmane.org 1252785910 29194 80.91.229.12 (12 Sep 2009 20:05:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2009 20:05:10 +0000 (UTC) Cc: lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 12 22:05:03 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MmYqE-0005FT-IL for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2009 22:05:03 +0200 Original-Received: from localhost ([127.0.0.1]:46781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmYqE-0002ss-1n for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2009 16:05:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MmYqA-0002rY-1b for emacs-devel@gnu.org; Sat, 12 Sep 2009 16:04:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MmYq5-0002qv-GU for emacs-devel@gnu.org; Sat, 12 Sep 2009 16:04:57 -0400 Original-Received: from [199.232.76.173] (port=36545 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmYq5-0002qs-Dy for emacs-devel@gnu.org; Sat, 12 Sep 2009 16:04:53 -0400 Original-Received: from mail-qy0-f181.google.com ([209.85.221.181]:40857) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MmYq2-0001q7-4L; Sat, 12 Sep 2009 16:04:50 -0400 Original-Received: by qyk11 with SMTP id 11so1736200qyk.1 for ; Sat, 12 Sep 2009 13:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=vsOTy6ylnOpJOmErsPtkGTGyAtkRWNITrclt6ApniCw=; b=KAtcWSVJQ4eVGXVgGA0IZQwMxuMYHygO/jFXzow1obknl3WXIr9KVTGXW5n+GiIzxR 07SzysBf6ySRDami4TAo3CKtVEdnCuwOzHaUPUXCRmXi+sqNwUUsQTUN6ZDFQt57w31g stgmd1famAsoaRXgSE0fbqEXDNpJM52ygvpHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=iPtISxdwYHHf5ROm7Pn/zJul4CerJ1cWaX97UBcJl3WCbcxTfRxxyN2RdQw26Twyeg zctRkaPbNpXgGoMYz102wgIPIJT42b2w4bfSL+8SegSckXSYmX3W/g16EirDe6ZT4YSO kuVvvu1O8IbxvBP9C8yBoZjLtJl99OK5WwVhw= Original-Received: by 10.229.41.13 with SMTP id m13mr1551540qce.85.1252785889232; Sat, 12 Sep 2009 13:04:49 -0700 (PDT) In-Reply-To: <83my50ymj5.fsf@gnu.org> X-Google-Sender-Auth: 14f77d46dc1c0ddd X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115249 Archived-At: --0016364173ade84b22047366f10a Content-Type: text/plain; charset=ISO-8859-1 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 > > Date: Sat, 12 Sep 2009 19:26:14 +0200 > > From: Antoine Levitt > > Cc: lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org > > > > > > Date: Sat, 12 Sep 2009 18:36:47 +0200 > > > > From: Antoine Levitt > > > > 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. > --0016364173ade84b22047366f10a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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.or= g/wiki/Polling_%28computer_science%29 , ie something like : check the s= tatus of the files by looking at their timestamps, wait a fixed timeout, an= d check again (which is terrible, I hope you agree). "poll" and &= quot;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 releva= nce to the action of watching for changes in a file, where poll and select = do the trick perfectly well.
2009/9/12 Eli Za= retskii <eliz@gnu.org<= /a>>
> Date: Sat, 1= 2 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.bor= gman@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 alway= s 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 t= o
get notifications. =A0This 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 sta= te 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 resour= ces
> (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<= br> > 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. =A0But that= 9;s not
how these notifications work (nor do I think it's a good idea for them<= br> 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&= #39;t
waste them too much.

--0016364173ade84b22047366f10a--