Garbage Collector and Foreign Threads

[Sean Kelly]

Sean Kelly wrote:
> 
> Right.  I think the GC will only be able to "see" the GUI thread if it 
> is the one which triggers the collection (this *might* not be true if 
> the GUI thread is the one that initializes the plugin, since a Thread 
> object is created for the "main" thread on app initialization, but it 
> sounds risky).

Just a clarification.  By the parenthesized statement I meant that the 
GC might be aware of the GUI thread if it is the one which initialized 
the library because this thread may well be considered the "main" 
thread.  After some consideration however, I don't think the GC will 
otherwise be aware of the GUI thread *even if it is the thread which 
triggers the collection*.  The pertinent bit of code in Phobos 1.009 is 
internal/gc/gcx.d lines 1466 to 1500.  As you can see, the GC only 
inspects threads in the list returned by Thread.getAll().  The GUI 
thread won't be in that list (ignoring the comment about it possibly 
being the "main" thread above) so its stack won't be inspected.  The GC 
could make the calling thread a special case and obtain its thread id, 
etc, manually, but that of breaks encapsulation for what is a pretty 
weird situation.

It may be worth seeing if the bit about the GUI thread being the "main" 
thread is valid.  If not, the best integrated approach would probably be 
to generate proxy thread objects or to add some other means of unmanaged 
threads to be suspended/inspected.  The safest approach for now, 
however, would likely be the producer/consumer method I mentioned in my 
prior post.


Sean