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: Wed, 17 Oct 2012 18:05:37 +0200 Message-ID: <83k3up2iem.fsf@gnu.org> References: <83ehkz4edw.fsf@gnu.org> <83bog33wdr.fsf@gnu.org> <837gqq49j7.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1350489946 15252 80.91.229.3 (17 Oct 2012 16:05:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2012 16:05:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 17 18:05:53 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 1TOW7v-00036d-Eu for ged-emacs-devel@m.gmane.org; Wed, 17 Oct 2012 18:05:47 +0200 Original-Received: from localhost ([::1]:53473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOW7o-0005X8-Ay for ged-emacs-devel@m.gmane.org; Wed, 17 Oct 2012 12:05:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOW7h-0005Vd-Cy for emacs-devel@gnu.org; Wed, 17 Oct 2012 12:05:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOW7b-0004UE-FC for emacs-devel@gnu.org; Wed, 17 Oct 2012 12:05:33 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:49137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOW7b-0004TF-7B for emacs-devel@gnu.org; Wed, 17 Oct 2012 12:05:27 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MC100A00ONLI000@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Wed, 17 Oct 2012 18:05:23 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MC1009YEOOZ9SJ0@a-mtaout22.012.net.il>; Wed, 17 Oct 2012 18:05:23 +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:154383 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Tue, 16 Oct 2012 17:43:26 -0400 > > > In any case, which one, pseudovector or misc, is better suited for > > this particular job, in your opinion? What would you use? > > I guess I'd go with the Lisp_Misc. OK, thanks. > The code to free the C struct will be the one you write > specifically for it, nobody else knows how to free it. Then the code that GC's this new Lisp object will have to be entirely specific to the layout of the struct I'm using, right? It won't be suitable even for the similar-but-different inotify code, right? If so, it's too bad: I hoped I could come up with some Lisp object that could be a wrapper for an arbitrary C struct, so that any similar feature that will need to pass opaque objects to Lisp could do that, instead of adding yet another object type. If it's possible to do this in some generic way, could you please explain how? > > That code must be run whenever the object is GC'ed, at the very least. > > It would be even better not to leave this to GC at all, but instead > > delete the object whenever the watch is canceled, since otherwise we > > leave behind a thread that does nothing except wasting system > > resources, for a time interval whose length cannot be predicted > > or controlled. > > If you make sure there's at most 1 file-watcher object per C struct, > then you can easily zero-out its pointer-field after freeing the > C struct, so you can make sure you protect yourself from > dangling pointers. And if you make sure the GC calls you back when > freeing the file-watcher, then you can make sure that you don't leak the > C structs. You mean, have the free_my_object function (to be called by GC) call my own code? Or is there a more generic way?