Garbage Collector and Foreign Threads

[Sean Kelly]

will75g wrote:
> Daniel Keep wrote:
>> So long as the GC knows about all the threads that *do* use GC'ed
>> memory, you're fine.
> 
> Unfortunately things are not that simple. The two most important threads 
> of my plug-in will be an audio processing thread and a GUI thread, both 
> created and managed by the hosting application (the host, not my 
> plug-in, runs the event loop).
> 
> The audio thread isn't really a problem: it's a real-time thread and 
> allocating memory inside it is not advisable even when coding with a 
> language without GC, so I'm used to that.
> 
> The real problem is the GUI thread: I really can't imagine making a GUI 
> and all the application logic without resorting on dynamic memory.
> 
> The ironic part of this is that if I only had these two threads, there 
> wouldn't be any problem, since the audio thread can't allocate or 
> dispose memory anyway, while the GUI thread could block for a collection 
> without causing any damage.
> The real problem is that I need at least another thread, created 
> internally by my plug-in, and this thread needs also to allocate memory. 
> If a collection is triggered by this third thread, the GC won't be able 
> to stop the GUI thread (since it doesn't know it) and that's where I 
> foresee problems.

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

If you're up for modifying Phobos, one thing that might work would be to 
modify std.thread such that proxy objects could be created for non-D 
threads.  Assuming this actually works, it might be the cleanest 
solution, though it would mean suspending your GUI thread while 
collections were in progress.  I think the alternative would be to 
access data from the plugin via some sort of communication mechanism.  A 
producer/consumer model, for example.  The GUI thread could issue 
requests to the plugin and then wait for a response.  Since this would 
all be happening within the plugin logic itself, this would all be 
invisible to the GUI code.


Sean