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: Lisp object that refers to a C struct Date: Thu, 18 Oct 2012 19:16:09 +0200 Message-ID: <83sj9b1z1i.fsf@gnu.org> References: <83ehkz4edw.fsf@gnu.org> <83bog33wdr.fsf@gnu.org> <837gqq49j7.fsf@gnu.org> <83r4ox3frd.fsf@gnu.org> <83ipa92i95.fsf@gnu.org> <83bog03jyf.fsf@gnu.org> <507F2C74.4070107@cs.ucla.edu> <83391c2xjq.fsf@gnu.org> <83wqyo1129.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1350580600 26142 80.91.229.3 (18 Oct 2012 17:16:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Oct 2012 17:16:40 +0000 (UTC) Cc: lekktu@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 18 19:16:46 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 1TOti0-0004Os-Fg for ged-emacs-devel@m.gmane.org; Thu, 18 Oct 2012 19:16:36 +0200 Original-Received: from localhost ([::1]:55335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOtht-0004fA-9o for ged-emacs-devel@m.gmane.org; Thu, 18 Oct 2012 13:16:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOthp-0004eb-Ho for emacs-devel@gnu.org; Thu, 18 Oct 2012 13:16:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOthj-0007Pc-FD for emacs-devel@gnu.org; Thu, 18 Oct 2012 13:16:25 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:53084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOthj-0007PX-6l for emacs-devel@gnu.org; Thu, 18 Oct 2012 13:16:19 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MC300400MLTHN00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 18 Oct 2012 19:15:52 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MC30032EMMGVWC0@a-mtaout22.012.net.il>; Thu, 18 Oct 2012 19:15:52 +0200 (IST) In-reply-to: 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:154415 Archived-At: > From: Stefan Monnier > Cc: Juanma Barranquero , eggert@cs.ucla.edu, em= acs-devel@gnu.org > Date: Thu, 18 Oct 2012 08:33:59 -0400 >=20 > >> In that case, wouldn't it be better to have the integer be an in= dex > >> into a table, like Stefan suggested? > > It's easy to do that (of course, at a price of some slightly more > > complicated memory management), >=20 > I don't understand why the memory management would care about which > integer you use to represent file-watcher descriptors. It doesn't. I meant the need to manage the table itself, grow it whe= n needed, etc. > > but I think Stefan still prefers the "new object" solution. >=20 > I generally like stronger types, so you're probably right, but an "= index > into a table" doesn't necessarily sound so terribly bad, if you hav= e > such a table anyway I don't have a table. What I have is an association list. I used th= e same method as R=FCdiger in his inotify patch. > (BTW, is this table usable by Lisp, e.g. can they get the list of > current file-watchers?). Yes, it's an alist. But it currently isn't exposed to Lisp, neither as a variable nor via an API. It could be, of course. But since R=FCdiger didn't, and since we didn't discuss in detail how this feat= ure will be used from Lisp, I didn't want to introduce APIs whose necessity is not clear. > >> It's faster to check that it is in range than compare it with an > >> arbitrarily long list of known pointers. > > That's not what the code does. It calls Fassoc_quit to find the I meant Fassoc, of course. > > descriptor in the list of known live watches (which will still be > > needed under the table suggestion), >=20 > Isn't Fassoc_quit going to "compare it with an arbitrarily long lis= t"? > To me this "list of known live watches" sounds exactly like the "ta= ble" > I mention above. Yes, but since it's an alist, I get its memory management for free. > > and then validates the pointer itself, just in case (which is als= o > > independent of the table suggestion). >=20 > What means "validate"? Call w32_valid_pointer_p, and in addition verify that the struct pointed to by it has the correct magic signature.