On Sunday, 6 August 2017 at 16:46:40 UTC, Mike Parker wrote:
On Sunday, 6 August 2017 at 16:23:01 UTC, bitwise wrote:

So I guess you're saying I'm covered then? I guess there's no reason I can think of for the GC to stop scanning at the language boundary, let alone any way to actually do that efficiently.

It's not something you can rely on. If the pointer is stored in memory allocated from the C heap, then the GC will never see it and can pull the rug out from under you. Best to make sure it's never collected. If you don't want to keep a reference to it on the D side, then call GC.addRoot on the pointer. That way, no matter where you hand it off, the GC will consider it as being live. When you're done with it, call GC.removeRoot.

I was referring specifically to storing gc_malloc'ed pointers on the stack, meaning that I'm calling a C++ function on a D call stack, and storing the pointer as a local var in the C++ function before returning it to D.

The more I think about it, the more I think it has to be ok to do. Unless D stores [ESP] to some variable at each extern(*) function call, then the GC would have no choice but indifference as to what side of the language boundary it was scanning on. If it did, I imagine it would say so here:

https://dlang.org/spec/cpp_interface.html#memory-allocation

Reply via email to