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: [PATCH] Added inotify support. Date: Mon, 08 Oct 2012 10:06:48 +0200 Message-ID: <83zk3x4cbr.fsf@gnu.org> References: <2181827.T3JxG88qQt@descartes> <83lifoa7hr.fsf@gnu.org> <87obkkcu92.fsf@wanadoo.es> <87lifkvoxl.fsf@spindle.srvr.nix> <87ehlbtv0r.fsf@spindle.srvr.nix> <87626ntowb.fsf@spindle.srvr.nix> <87txu7s31q.fsf@spindle.srvr.nix> <87haq6ell2.fsf@uwakimon.sk.tsukuba.ac.jp> <877gr1e921.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1349683681 9986 80.91.229.3 (8 Oct 2012 08:08:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Oct 2012 08:08:01 +0000 (UTC) Cc: nix@esperi.org.uk, ofv@wanadoo.es, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 08 10:08:07 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TL8Ni-0005YX-OW for ged-emacs-devel@m.gmane.org; Mon, 08 Oct 2012 10:08:06 +0200 Original-Received: from localhost ([::1]:59691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL8Nc-0001rG-1Q for ged-emacs-devel@m.gmane.org; Mon, 08 Oct 2012 04:08:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL8NR-0001qc-Gz for emacs-devel@gnu.org; Mon, 08 Oct 2012 04:07:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TL8NK-0003IO-5v for emacs-devel@gnu.org; Mon, 08 Oct 2012 04:07:49 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:54703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL8NJ-0003IE-U0 for emacs-devel@gnu.org; Mon, 08 Oct 2012 04:07:42 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MBK00F00EFBDL00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 08 Oct 2012 10:06:56 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBK00E2MEJJVU90@a-mtaout22.012.net.il>; Mon, 08 Oct 2012 10:06:56 +0200 (IST) In-reply-to: <877gr1e921.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154218 Archived-At: > From: "Stephen J. Turnbull" > Date: Mon, 08 Oct 2012 16:07:18 +0900 > Cc: Nix , =C3=93scar Fuentes , > =09emacs-devel@gnu.org >=20 > According to nix, inotify is unreliable, end of discussion. >=20 > If so, it may make sense to back up inotify with polling, although = at > a greatly reduced rate. Also, files may get moved across filesyste= ms > which support different mechanisms, etc, etc. So allowing differen= t > files to get notifications in different ways, and perhaps even > changing backends on the fly may be useful/necessary for maximum > reliability. If one wants a 100% reliability, polling cannot be done at slower rates without degrading response times. Some applications might not like the long response times. And of course, you won't know when the notifications are less reliable than you would like to, so selectivel= y increasing the polling rate in those problematic cases seems impossible. Moreover, both inotify and the equivalent Windows APIs are documented to lose notifications on a busy filesystem, so even a perfectly local file/directory cannot be watched with 100% reliability. And that is even before we think about the effects of the internal Emacs mechanisms of handling these events. E.g., if there's a lot of input from the keyboard and the window system, and if some heavy Lisp is running, it is quite possible to have the file-notification event be stuck in limbo for some time, before Emacs examines it and takes action. IOW, this will work well "most of the time", but that's about it.