FAQ for developers
- What is the GC proxy in GC implementations about?
One of the requirements for DRuntime was that it must allow a D dynamic library to be built. On Windows, this means that the DLL will have a full runtime and GC and the app will also have a full runtime and GC. To simplify data sharing between the DLL and the app, there must be a way to have allocations in the DLL use the app's GC instead. So on Windows when a D app loads a D DLL it sets the proxy handle to accomplish this. Maybe this is not the best, but it seems necessary for the moment. Certainly on Windows anyway. This proxy is not present in the public interface because its used only by the DRuntime, it's not intended to be used by the library users.
- Why many modules (like the GC implementations) declare extern (C) functions instead of importing some core.* module?
Each portion of the runtime is designed to be built as a standalone entity--ie. without importing any headers other than OS or standard C headers. One reason for this is so that a GC, for example, could be created without any implementation-level dependencies on core, so if the core implementation changes the GC doesn't need to be rebuilt (which would be necessary if the -inline flag were set, for example). In the long run, the DRuntime project should not exist at all. Instead, compiler developers should develop their own compiler runtime according to the spec, GC developers a GC according to the spec, etc.
- Why thread_needLock() returns true when the program has ever been multithreaded at any point in its execution and whether more than 1 thread is currently running?
Typically, the stores of a terminating thread are only guaranteed to be visible when join() returns for that thread... and then to the joining thread only. While it's true that the stores will eventually be visible to all threads in a program, there's no easy way to figure out exactly when this is (the lock-free people would probably say you'd have to wait for a "quiescent state"). I also don't know of any apps that are multi threaded for a while and then later become single threaded, so the issue of performance loss seems like somewhat of a corner case.