Re: Lisp object that refers to a C struct

[Stefan Monnier]

>> 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