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: Fri, 19 Oct 2012 09:14:49 +0200 Message-ID: <83bofz0w7q.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> <83sj9b1z1i.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 1350630979 27494 80.91.229.3 (19 Oct 2012 07:16:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2012 07:16:19 +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 Fri Oct 19 09:16:26 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 1TP6oh-0003E7-Bg for ged-emacs-devel@m.gmane.org; Fri, 19 Oct 2012 09:16:23 +0200 Original-Received: from localhost ([::1]:43563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TP6oa-00013r-2r for ged-emacs-devel@m.gmane.org; Fri, 19 Oct 2012 03:16:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TP6oW-00013T-AP for emacs-devel@gnu.org; Fri, 19 Oct 2012 03:16:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TP6oS-0005IY-1L for emacs-devel@gnu.org; Fri, 19 Oct 2012 03:16:12 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:53510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TP6oR-0005IT-PE for emacs-devel@gnu.org; Fri, 19 Oct 2012 03:16:07 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MC400C00PANTI00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 19 Oct 2012 09:15:00 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MC400CWCPGZPW40@a-mtaout20.012.net.il>; Fri, 19 Oct 2012 09:15:00 +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.166 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:154437 Archived-At: > From: Stefan Monnier > Cc: lekktu@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Thu, 18 Oct 2012 18:09:46 -0400 >=20 > > It doesn't. I meant the need to manage the table itself, grow it= when > > needed, etc. >=20 > To me "table" doesn't imply "array". It's just some kind of > data-structure that keeps the elements at hand. It can be a list, = an > array, a tree, a has-table, you name it. If we use a Lisp data structure, then the same issue of putting a bar= e pointer into that started this thread it pops up again, doesn't it? Anyway, a Lisp data structure is what I have now. > >> (BTW, is this table usable by Lisp, e.g. can they get the list o= f > >> current file-watchers?). > > Yes, it's an alist. But it currently isn't exposed to Lisp, neit= her > > 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 = feature > > will be used from Lisp, I didn't want to introduce APIs whose > > necessity is not clear. >=20 > Note that if we use integers instead of a new type, we can't free > those structs when the Lisp code loses the last reference to the > file-watcher. The list is maintained by 2 primitives, which take care of that. And the list itself is statically protected from GC. If some disaster strikes and the list is somehow thrashed or released by some evil magic, then all we have is a bunch of threads watching file-change notifications that no one can hear, threads which can only be stopped by shutting down Emacs. Not too bad, considering the doomsda= y scenario under which it can happen. > > Call w32_valid_pointer_p, and in addition verify that the struct > > pointed to by it has the correct magic signature. >=20 > Why is that needed? To make sure we never dereference a pointer that doesn't point to the watch object. Since the remove-watch API accepts a Lisp integer, it could be called with any arbitrary integer value. IOW, I don't want to crash, even if somehow a bad pointer is found in the alist described below. > Can you give a precise description of your alist? It's an alist of cons cells like this: (DESCRIPTOR . CALLBACK) where DESCRIPTOR is a pointer to the C struct as a Lisp integer, and CALLBACK is a function to call when the file notification event comes in. A single cons cell describes a single file-change notification request; each such request allocates another C struct (and thus gets another DESCRIPTOR) and starts another thread. As I wrote, the reason for this design of the alist was to be 100% compatible with what R=FCdiger did. Otherwise, I could keep CALLBACK= in the C struct as well, for example.