On 2015-03-15 15:57:43 +0000, Marc Schütz said:
Ok. I need to dig into how the interpreter handles the returned pointer
and how the stack is handled.
C usually uses manual memory management, therefore I would expect that
the interpreter actually documents whom the pointer belongs to, and who
is responsible for cleaning it up.
What I'm trying to understand is how the returned pointer is used and
when the GC can kick in.
I tracked the return code from the DLL. The returned pointer is
returned in EAX register (conforming to the C calling convention). Then
the interpreter uses this pointer for some time (in my case to create a
copy).
It than continues, and at some point the EAX register gets some other
value. This is the point, wher no reference to the D GC allocated
memory can anylonger be found. Hence the GC should be free to free the
memory.
If the interpreter takes ownership, you should just allocate the data
with malloc(), and the interpreter will then call free() on it when it
doesn't need it any longer. Not sure whether .dup is compatible with
that, maybe you'd need to write a small helper that copies things to
the C heap.
Yes, exactly. And the problem is, that it's not clear to me (yet) when
the interpreter takes ownership and when not.
Am I right, that I can query() the D GC to check if a pointer is known
/ can be found or not?
It would be cool if I could query D from the interpreter and ask: "Will
this pointer be freed in the next collector run?" and get back: Yes, or
"already has been".
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
