David Vallner wrote:
> Da Piatok 10 Februr 2006 05:10 Joel VanderWerf napsal:
>> Any ideas? If Thread#stop is a bad idea, what is the right idea in this
>> case?
> 
> Letting threads directly play tricks on each other is more of a Q'n'D hack 
> than a real parallelism solution. What you're looking for sounds like a latch 
> construct that the user process opens and closes for the other threads. Brief 
> googling indicates you could use something called a read-write mutex / lock.
> 
> Maybe there's a ruby implementation out there already, if not, it should be 
> doable via Mutexes and Semaphores. (Do we have Semaphores in the core or 
> stdlib?)
> 
> David Vallner
> 

I agree that Thread#stop is not a good tool for writing concurrency 
constructs, and Thread.stop should be used instead, as it is in the 
implementations of Mutex et al. Thread#stop is bad because the stopped 
thread can be stopped in a way that the thread cannot predict or control 
(except that it can prevent being stopped by being in Thread.critical). 
But that's exactly why I want it.

Think of this as a remote debugger (in fact, it is). I need all threads 
to stop wherever they are except the ones being used to debug the 
process. If there were a Thread.critical that applied to all threads in 
the DRb ThreadGroup, I'd be happy.

As I understand it, a latch would not serve this purpose. A latch stops 
newly created threads from running until the latch is opened. In ruby 
this would be easy to implement using Thread.stop within the block of 
each thread. Then another thread can wakeup those threads as needed:

   th = Thread.new { Thread.stop; do_some_work }
   prepare_for_th_to_run
   th.wakeup



-- 
        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407