From: Brian Candler <b.candler@...>
Date: 2008-09-21T03:38:59+09:00
Subject: Re: Garbage collecting threads?

David Masover wrote:
>> If the farmer and the workers form an isolated subgraph of objects - 
>> e.g. there are no other references to them from the stack or from global 
>> variables or from other objects - then they will all be garbage 
>> collected together.
> 
> Unless the worker includes a running Thread. Since Ruby does not solve 
> the
> Halting Problem, it can't predict what that Thread will do, and thus, 
> can't
> discard anything still referenced by the thread.

A thread of execution has its own stack, and any object references on 
the stack will prevent those objects from being garbage-collected, yes.

If you're saying that each worker is a thread, and each worker has a 
reference to the farmer, then indeed that will stop the farmer from 
being garbage-collected.

But I see no reason for the worker to have a reference to the farmer. 
All it needs is a reference to the queue, to pick up things to do. The 
input queue can also contain instructions as to where to send the 
results, or you can have a separate output queue.

Then in theory, when no-one has a reference to the farmer it will be 
GC'd, and at that point the finalizer can deal with all the threads (the 
finalizer will need to have access to the queue to send 'stop' messages, 
or to the array of threads in order to kill them)

Unfortunately in practice with ruby-1.8, the farmer seems to end up on 
the thread's stack too for some reason. But even then it can be made to 
work, with care: you need to create all the worker threads first, *then* 
create the farmer object to hold them. As long as you don't need to add 
new workers dynamically, that should be fine.
-- 
Posted via http://www.ruby-forum.com/.