Foreign threads in D code.

[Biotronic via Digitalmars-d-learn]

On Wednesday, 12 July 2017 at 09:10:07 UTC, Jacob Carlborg wrote:
> On 2017-07-11 08:18, Biotronic wrote:
>
>> If DRuntime is not made aware of the thread's existence, the 
>> thread will not be stopped by the GC, and the GC might collect 
>> memory that the thread is referencing on the stack or in 
>> non-GC memory.
>
> Are you sure? Wouldn't that make malloc or any other custom 
> allocators completely useless and the D GC would completely 
> break the C standard library because it could collect memory 
> allocated by the C standard library?
>
> From "How Garbage Collection Works":
>
> "5. Freeing all **GC** allocated memory that has no active 
> pointers to it and do not need destructors to run" [1]. I added 
> the emphasize on "GC".
>
> From "Interfacing Garbage Collected Objects With Foreign Code"
>
> "If the only pointer to an object is held outside of these 
> areas, then the collector will miss it and free the memory. To 
> avoid this from happening, either
> * reallocate and copy the object using the foreign code's 
> storage allocator or using the C runtime library's 
> malloc/free." [2].
>
> [1] http://dlang.org/spec/garbage.html#how_gc_works
> [2] http://dlang.org/spec/garbage.html#gc_foreign_obj

That's basically what I tried to say - the GC may collect memory 
*it has allocated* if the only pointers to it are in memory the 
GC doesn't scan (i.e. on the stack of an unregistered thread or 
in memory not allocated via the GC).

It will not collect memory allocated by other means, but that 
Foo* you got from D and are using in C++ might point to a Bar 
soon after the GC runs.

--
   Biotronic