will75g wrote:
> 
> If I understand correctly being able to block the foreign thread is not enough, because the GC must also be able to inspect the thread stack.

Yes.  And the thread which initiates the collection doesn't need to be blocked (since it's running the collection) but its stack still must be inspected, assuming it holds references to GCed data.

> If
> that's the case, your proxy thread idea is probably the cleanest solution. I'll see if I can manage to implement it (having something like that in Tango would be fantastic).

To do this, I suggest looking at how the proxy for the main thread is set up in std.thread.Thread.thread_init().  Tango does something similar in thread_init() within tango.core.Thread.

Let me think about this a bit more to make sure I can't think of any weird problems with the approach and if not then I'll add the feature to Tango.


Sean

Chris Warwick wrote:
> I assume you are doing VST plugins? Anycase i've played round with that a bit (not in D) so I'd be interested in hearing how you get on with it ;-)

Yes, it's a VST plug-in. Currently I'm only evaluating how feasible is to create audio plug-ins in D and this GC issue is the first road block, so unfortunately there isn't much I can say.

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...

Frits van Bommel will75g wrote:
> 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...

Yes, by PC I mean win32... unfortunately linux is rather irrelevant for audio applications.
The solution you're proposing would work with the simplified model I described. But audio plug-ins are a mess... The whole truth is that you're guarantee to have a GUI and an audio thread, but there could be more. Some notifications from the host are performed from an unspecified thread: it can be the GUI thread, the audio thread or a completely different thread, there's no standard for this and each host implements it in a different way, so the plug-in must be able to adapt to every possible situation... That's way I look for a generic solution. Being able to identify a foreign thread and wrapping it in a proxy thread looks like the most promising solution so far.