Isaac Jurado <address@hidden> writes:
> On Thu, Jun 27, 2019 at 9:52 PM Greg Troxel <address@hidden> wrote:
>
>> I have been down this path before, with guile and with lua. Basically,
>> if C (or non-scheme) has a pointer to a scheme object, then you need to
>> hold a logical reference for it and protect the scheme object, and when
>> the C pointer is dropped decrease the refcnt.
>>
>> I am unclear on the details of how you have a ref that gc is made aware
>> of. One way is to have a scheme array of the object and a count, and
>> have the code null out the object when the count goes to zero or
>> something like that. But the point is that you need to have a proxy in
>> the scheme world, visible to gc, when a pointer to a scheme object is
>> held outside of the scheme world.
>>
>
> That's more or less what I had in mind, although instead of an array I
> would use a hash table indexed by a fundamental type (e.g. integer) which
> can be converted painlessly between Scheme and C.
Sure - it just needs to be something the gc will find.
My intention was quite the opposite, use something that the GC will NOT find, like 32/64 bit integers. I assumed that (pointer->procedure) and its inverse would convert from/to uint32, uint64, etc. natively, without creating GC objects. This way I can safely give a way such a value to the C code, while using it as a key to a Scheme hashmap.
Just because something wasn't collected doesn't mean it is safe. You
don't actually know that the closure wasn't garbage collected, just that
when you used it the bits were still there. You might try running under
valgrind. Or modify guile to clear all objects that are garbage
collected, which I'm guessing it doesn't do.
Agreed, just like the old use after free().
In my experience, it's definitely not ok to capture a pointer to a
scheme object and store it for later use without protecting the scheme
object from gc by holding a reference.
Best regards.