From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?R=FCdiger?= Sonderfeld Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Added basic file system watching support. Date: Fri, 28 Sep 2012 18:27:04 +0200 Message-ID: <1604303.YKOVcvQH0F@descartes> References: <6218185.ViukoKRdFp@descartes> 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 1348857300 20296 80.91.229.3 (28 Sep 2012 18:35:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2012 18:35:00 +0000 (UTC) Cc: Leo , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 28 20:35:06 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 1THfOy-0008En-QJ for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2012 20:35:04 +0200 Original-Received: from localhost ([::1]:59223 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THfOt-0005ea-In for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2012 14:34:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THfOq-0005dn-Rk for emacs-devel@gnu.org; Fri, 28 Sep 2012 14:34:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THdPF-0002kK-Fm for emacs-devel@gnu.org; Fri, 28 Sep 2012 12:27:21 -0400 Original-Received: from ptmx.org ([178.63.28.110]:48320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THdPF-0002jq-92 for emacs-devel@gnu.org; Fri, 28 Sep 2012 12:27:13 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by ptmx.org (Postfix) with ESMTP id 695F1220FF; Fri, 28 Sep 2012 18:27:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ptmx.org Original-Received: from ptmx.org ([127.0.0.1]) by localhost (ptmx.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHVUzfz1iYXs; Fri, 28 Sep 2012 18:27:09 +0200 (CEST) Original-Received: from descartes.localnet (chello080108246092.7.14.vie.surfer.at [80.108.246.92]) by ptmx.org (Postfix) with ESMTPSA id 9A1D82009E; Fri, 28 Sep 2012 18:27:09 +0200 (CEST) User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic; KDE/4.8.5; x86_64; ; ) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 178.63.28.110 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:153691 Archived-At: Thank you for your reply! On Friday 28 September 2012 10:13:52 you wrote: > I'm not very familiar with inotify and other file-system watching > facilities, so just as a guideline for others's reviews: I'm OK with > installing in 24.3 a non-complete version of the code, and I'm OK to > install before the freeze a code that needs more testing, *but* only = if > those missing functionalities and testing won't require a redesign of= > the API. It could require a minor redesign of the API. At least I want to gathe= r some=20 experience using the API first. And maybe porting it to other systems = will=20 require API adjustments. Both BSD's and Windows' filesystem watch APIs= are=20 not as powerful as inotify. > I understand that NAME refers to the added/removed file, but I'm > wondering why we don't also add FILENAME (the name of the directory) = to > the event. If inotify doesn't provide it, we can provide it > ourselves, right? > Or is it rarely/never needed? > Or is it because that directory may change name without us knowing? The name might change. This would require file-watch to register MOVE_= SELF=20 events for every watched file and then update the name. This would mak= e the=20 code quite complicated and worst of all leave the user wondering why th= e name=20 suddenly changed unless we force him to always accept MOVE_SELF events.= Which=20 would then again impose something on the user he might not need. There= fore I=20 think it is better if the user keeps track of any ID to FILENAME mappin= g=20 himself. Maybe there could be some user defined storage in the ID to h= andle=20 it. > I can't remember enough of the context, but objects that are "unique"= > are plentiful. A cons cell would do, regardless of its value, for > example (now, as to whether it's better than a number, that depends o= n > what it's use for, e.g. whether you can put the cons's fields to good= > use). Currently the only risk is that cookie is bigger than MOST_POSITIVE_FIX= NUM and=20 then gets mapped to a value that is already taken by another cookie. T= his is=20 only a problem on 32bit systems without the use of wide-int because coo= kie is=20 uint32_t. There is a similar problem with the watch descriptor. It is currently = also=20 stored in the ID with make_number. Inotify uses an incremental system = for=20 watch descriptors and should be run out of descriptors by the time=20 MOST_POSITIVE_FIXNUM is reached. But there is no guarantee for it. Th= erefore=20 something like SAVE_VALUE should probably be used. Regards R=C3=BCdiger