Garbage Collector and Foreign Threads

[Frits van Bommel]

will75g wrote:
> Chris Warwick wrote:
> 
>> 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.
> 
> Probably that would work on win32, but I have to support both Mac and 
> PC, and if I remember correctly in OSX it's forbidden to call any GUI 
> related coded from a thread that is not the main application thread (a 
> simple operations such as invalidating a window area would cause a 
> crash). Things are even more complicated if you add the fact that my 
> plug-in GUI must live in a child window of the host window.

So that would mean the GUI thread of your plugin would have to be the 
main thread?
Then perhaps the proxy object created by std.thread for the main thread 
mentioned somewhere in this thread would be able to handle this on OSX, 
and you could use above method for win32?
(Assuming by 'PC' above you meant win32, and not e.g. Linux as well. If 
you also need to support other PC platforms, you'll need to figure out 
what works there)
You may want to create some kind of OS abstraction layer for this if you 
try to implement it.

This is obviously not as nice as a cross-platform solution. On the other 
hand, it might actually work. Which is after all a very important 
quality for a program to have...