From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs inotify support? Date: Sat, 12 Sep 2009 22:45:50 +0300 Message-ID: <83my50ymj5.fsf@gnu.org> References: <6fa54e4e0909111554g4165418albbdffc142b3b52ee@mail.gmail.com> <83tyz8z3sl.fsf@gnu.org> <6fa54e4e0909120936s24634600sf00a818aabd308ce@mail.gmail.com> <83r5ucyuf0.fsf@gnu.org> <6fa54e4e0909121026t797ee747yc2ac395314c3cc40@mail.gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1252784768 26471 80.91.229.12 (12 Sep 2009 19:46:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2009 19:46:08 +0000 (UTC) Cc: lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org To: Antoine Levitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 12 21:46:00 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 1MmYXo-0000WN-Kv for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2009 21:46:00 +0200 Original-Received: from localhost ([127.0.0.1]:54863 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmYXn-0006ZW-Sg for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2009 15:45:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MmYXh-0006Xi-HD for emacs-devel@gnu.org; Sat, 12 Sep 2009 15:45:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MmYXg-0006X2-LU for emacs-devel@gnu.org; Sat, 12 Sep 2009 15:45:53 -0400 Original-Received: from [199.232.76.173] (port=54208 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmYXg-0006Wv-Gx for emacs-devel@gnu.org; Sat, 12 Sep 2009 15:45:52 -0400 Original-Received: from mtaout3.012.net.il ([84.95.2.7]:13644) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MmYXg-00081y-01 for emacs-devel@gnu.org; Sat, 12 Sep 2009 15:45:52 -0400 Original-Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KPV00200IHMRJ00@i_mtaout3.012.net.il> for emacs-devel@gnu.org; Sat, 12 Sep 2009 22:45:50 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.50.163]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KPV005VJIWDRX50@i_mtaout3.012.net.il>; Sat, 12 Sep 2009 22:45:50 +0300 (IDT) In-reply-to: <6fa54e4e0909121026t797ee747yc2ac395314c3cc40@mail.gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 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:115248 Archived-At: > 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.