From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Lisp object that refers to a C struct
Date: Tue, 16 Oct 2012 17:43:26 -0400 [thread overview]
Message-ID: <jwvtxtuhzg0.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <837gqq49j7.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 16 Oct 2012 19:22:04 +0200")
>> 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
next prev parent reply other threads:[~2012-10-16 21:43 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-15 21:24 Lisp object that refers to a C struct Eli Zaretskii
2012-10-16 1:07 ` Stefan Monnier
2012-10-16 3:53 ` Eli Zaretskii
2012-10-16 13:11 ` Stefan Monnier
2012-10-16 17:22 ` Eli Zaretskii
2012-10-16 21:43 ` Stefan Monnier [this message]
2012-10-17 4:05 ` Eli Zaretskii
2012-10-17 6:21 ` Stephen J. Turnbull
2012-10-17 15:50 ` Eli Zaretskii
2012-10-17 17:45 ` Stephen J. Turnbull
2012-10-17 13:34 ` Stefan Monnier
2012-10-17 16:08 ` Eli Zaretskii
2012-10-17 20:23 ` Stefan Monnier
2012-10-17 20:46 ` Eli Zaretskii
2012-10-17 22:08 ` Paul Eggert
2012-10-18 0:22 ` Stefan Monnier
2012-10-18 3:43 ` Stephen J. Turnbull
2012-10-18 4:50 ` Eli Zaretskii
2012-10-18 7:20 ` Paul Eggert
2012-10-18 11:09 ` Eli Zaretskii
2012-10-18 16:42 ` Paul Eggert
2012-10-18 17:21 ` Eli Zaretskii
2012-10-18 8:52 ` Juanma Barranquero
2012-10-18 11:17 ` Eli Zaretskii
2012-10-18 12:33 ` Stefan Monnier
2012-10-18 17:16 ` Eli Zaretskii
2012-10-18 22:09 ` Stefan Monnier
2012-10-19 7:14 ` Eli Zaretskii
2012-10-19 14:44 ` Stefan Monnier
2012-10-19 18:54 ` Eli Zaretskii
2012-10-19 21:35 ` Stefan Monnier
2012-10-19 22:35 ` Eli Zaretskii
2012-10-20 1:52 ` Stefan Monnier
2012-10-20 8:34 ` Eli Zaretskii
2012-10-17 16:05 ` Eli Zaretskii
2012-10-17 16:59 ` Davis Herring
2012-10-17 20:27 ` Stefan Monnier
2012-10-17 21:02 ` Eli Zaretskii
2012-10-18 0:23 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvtxtuhzg0.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.