Garbage Collector and Foreign Threads
Chris Warwick
sp at m.me.not
Mon Mar 19 17:57:55 PDT 2007
"Sean Kelly" <sean at f4.ca> wrote in message
news:etn7tt$2p86$1 at digitalmars.com...
> 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.
asumming win32 here as thats all i know but..
Couldnt the plugin create a local GUI thread? So when the host requests a
plugin instance, the dll actually creates a local thread that has it's own
windows message loop and that basicly runs the plugin and gui. So as long as
the host gui and audio thread dont cause any allocations or interfer in a
way that would break the gc, it should work? Of course some way for the
threads to interact / comunicate would need to be worked out but at least by
creating your own thread you can controll where the allocations occur. With
modern multicore it could be posible that more than one host gui thread
exists? And that would be very problematic i think.
cw
More information about the Digitalmars-d-learn
mailing list