On 10/25/20 3:19 AM, rikki cattermole wrote:
On 25/10/2020 11:03 PM, Ali Çehreli wrote:
Does the GC see that local variable 'name' that is on the C side? What I don't know is whether the GC is aware only of the stack frames of D functions or the entire thread, which would include the C caller's 'name'.

The thread stack frame that is registered with the D GC will know about the D side and may know about the C side.

It depends on what the C side is doing.

If the C side went ahead and made a new stack frame via a fiber... it won't know about it. But even if it did, the D stack frame is still alive and pinning that bit of memory.

Ultimately, if the C side puts that pointer some place like a global or send it to another thread, there are no guarantees that things will play out well.

Sorry to bring this up again but I want to understand this fully before I say something wrong during my DConf presentation. :)

The D code is a library. The actual program is e.g. written in C. When the D library is loaded into the program, the following function is executed and the D GC is initialized:

pragma (crt_constructor)
extern(C) int initialize() {
  return rt_init();
}

Does the D GC know the complete function call stack of the C program all the way up from 'main'? Is there the concept of "bottom of the stack" or does the D GC can only know the value of the stack pointer at the time rt_init() was called. If the latter, then I think a toStringz string may not be alive in a C function.

Imagine the C program dlopens our library from inside a function called from main. Then the program calls one of our library functions from another function in main:

// C program
int main() {
  initializeDlibrary();  // This does dlopen()
  useDlibrary();    // This receives a string returned from
                    // toStringZ and uses that string.
}

So, the question is, does D GC only know initializeDlibrary's stack frame up because it was initialized there?

I know threads complicate matters and they need to be attached to the GC with core.thread.osthread.thread_attachThis but I am not there yet. :) I want to understand the basic single thread stack pointer issue first.

Thank you,
Ali

Reply via email to