Threading and the Garbage handler mess.

[Sergey Gromov]

Alan Knowles <alan at akbkhome.com> wrote:
> "THE GC AS DELIVERED IS COMPLETELY BROKEN FOR REAL THREADED APPLICATONS

Isn't it a bit overstated?

You basically say that memory could be prematurely freed if an external 
non-D function stores a pointer to GC-allocated memory internally.  This 
is quite different from "COMPLETELY BROKEN" to me.  You don't even 
mention that for both extern(C) and extern(Windows) pointers are pushed 
on stack so that memory is protected at least until the external 
function returns.  Well it *can* overwrite its arguments with an 
unrelated data, but in all other scenarios your memory is protected.

The solutions are:

1. Don't bother.  This is the correct approach for most of CRT and Win32 
functions because they do not store pointers.

2. Write wrappers.  If you must use a non-pure, non-reentrant C library 
which stores pointers, or returns malloc'd memory,---then yes, you must 
understand how GC works, how to protect GC-allocated memory, and how to 
make GC handle externally-allocated memory.

3. Write D-aware external functions.  If you implement them yourself you 
can always copy memory instead of storing raw pointers, so that you can 
follow solution 1 when writing D code.