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 20:54:32 +0200 Message-ID: <83txtqz40n.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> <83bofz0w7q.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 1350672894 11830 80.91.229.3 (19 Oct 2012 18:54:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2012 18:54:54 +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 20:54:58 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 1TPHik-0000y6-Ft for ged-emacs-devel@m.gmane.org; Fri, 19 Oct 2012 20:54:58 +0200 Original-Received: from localhost ([::1]:46872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPHid-0006Q2-6T for ged-emacs-devel@m.gmane.org; Fri, 19 Oct 2012 14:54:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPHiZ-0006Pi-Ar for emacs-devel@gnu.org; Fri, 19 Oct 2012 14:54:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TPHiY-0002F9-0O for emacs-devel@gnu.org; Fri, 19 Oct 2012 14:54:47 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:57112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPHiX-0002Eq-O4 for emacs-devel@gnu.org; Fri, 19 Oct 2012 14:54:45 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MC500L00LNFTM00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Fri, 19 Oct 2012 20:54:44 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MC500LA7LV7OU70@a-mtaout23.012.net.il>; Fri, 19 Oct 2012 20:54:44 +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.175 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:154449 Archived-At: > From: Stefan Monnier > Cc: lekktu@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Fri, 19 Oct 2012 10:44:32 -0400 >=20 > >> > It doesn't. I meant the need to manage the table itself, grow= it when > >> > needed, etc. > >> 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 lis= t, an > >> array, a tree, a has-table, you name it. > > If we use a Lisp data structure, then the same issue of putting a= bare > > pointer into that started this thread it pops up again, doesn't i= t? > > Anyway, a Lisp data structure is what I have now. >=20 > In any case, the code now does keep a table of those C structs, and= they > are not reclaimed when the Lisp code loses the last "handle". > Instead they are only reclaimed when the Lisp code calls > remove-watch explicitly. That's true. The reason is that the C struct cannot be reclaimed as long as the watcher thread runs, because that thread constantly dereferences a pointer to the struct. The remove-watch API takes car= e of orderly shutting down the thread (which is not trivial, because it is mostly stuck in a system call), and then frees the struct. > This design means we don't need a "finalizer" (i.e. code in gc_swee= p > that calls us back to free the C struct), but it also means that we= may > "leak" those C structs if the Lisp code just forgets to `remove-wat= ch'. Correct. > I think that's OK for now. I concur. > >> > Call w32_valid_pointer_p, and in addition verify that the stru= ct > >> > pointed to by it has the correct magic signature. > >> 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. >=20 > But as long as the table is not corrupted, there's no risk of such > a thing happening anyway. Right. > > IOW, I don't want to crash, even if somehow a bad pointer is foun= d in > > the alist described below. >=20 > OK, so it's just done out of paranoia. That's fine, but please mak= e it > clear in the code, e.g. by placing it in an eassert. Will do. > > 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 CALL= BACK in > > the C struct as well, for example. >=20 > I think it's OK. Encoding C pointers in Lisp integers is pretty ug= ly, > so we should make sure that no part of the design depends on it (so= it > can be changed in the future) Well, the way to get the pointer to the struct given the descriptor and vice versa _will_ have to change if the design changes. Other than that, nothing depends on that. > and we should also make it very clear in the doc that Elisp code > should not rely on those handles being integers (treat them as blac= k > boxes instead). They are documented as "descriptors". I will see if there's a place to make the point you want to drive home. Anyway, I guess I'm waiting for R=FCdiger to install his changes, is that right?