From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Lisp object that refers to a C struct Date: Tue, 16 Oct 2012 17:43:26 -0400 Message-ID: References: <83ehkz4edw.fsf@gnu.org> <83bog33wdr.fsf@gnu.org> <837gqq49j7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1350423816 6987 80.91.229.3 (16 Oct 2012 21:43:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Oct 2012 21:43:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 16 23:43:43 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 1TOEvL-000083-T6 for ged-emacs-devel@m.gmane.org; Tue, 16 Oct 2012 23:43:40 +0200 Original-Received: from localhost ([::1]:46844 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOEvF-0004ho-0m for ged-emacs-devel@m.gmane.org; Tue, 16 Oct 2012 17:43:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOEvC-0004hi-PT for emacs-devel@gnu.org; Tue, 16 Oct 2012 17:43:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOEvB-0003Qs-Qy for emacs-devel@gnu.org; Tue, 16 Oct 2012 17:43:30 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:45001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOEvA-0003QV-2G; Tue, 16 Oct 2012 17:43:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09MCoeh/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOjM4FYgwWBOgQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="201833495" Original-Received: from 76-10-135-161.dsl.teksavvy.com (HELO pastel.home) ([76.10.135.161]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 16 Oct 2012 17:43:27 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C7A0F59520; Tue, 16 Oct 2012 17:43:26 -0400 (EDT) In-Reply-To: <837gqq49j7.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 16 Oct 2012 19:22:04 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:154374 Archived-At: >> Then you need to add the corresponding switch branches in print.c and in >> alloc.c. > Can I just use PVEC_OTHER instead? No, for the same reason as Lisp_Save_Value: you can't give a nice printed representation. > 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. >> The other question is "when should we free the C struct to which this >> new lisp_misc points"? And that depends. You could have the GC free it >> when it finds your lisp_misc can be freed, or you could have instead >> a notion of "deleted file-watcher" (like we have for >> buffers/windows/...) which is when the underlying C struct has been >> freed (but of course, this state needs to be represented, e.g. by >> setting the pointer to NULL, which means that you need to be able to >> enumerate all the file-watcher objects (or the only one, if you enforce >> there can only be one) corresponding to a particular C struct). > This sounds dangerous in my case. Of course, but it's unavoidable: you want to export to Elisp a pointer to a C struct. So you have to deal with the two risks: failing to free the object, and having Elisp code use the object after it was freed. > notifications. It is unthinkable to let any code outside of the one > specifically written for this to free that struct, because the > associated thread will go down in flames and take Emacs with it. Of course. The code to free the C struct will be the one you write specifically for it, nobody else knows how to free it. > 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. > Is there a clean way of doing that? AFAIK this *is* the clean way. > pure overhead, with no benefits at all. To do everything I need with > the watcher struct, all I need is a pointer to it, which can easily be > disguised as a Lisp integer. (This is how the code actually works > now.) What happens if someone passes you this same integer some time after you've freed the C struct? Stefan