Thread#stop

[Joel VanderWerf]

Is it possible for one thread to put another thread in a stop (or sleep)
state? (Unlike Thread.stop which stops the current thread.)

The answer is currently no (Thread#stop was removed at one point), and
Matz has said he doesn't think this should be allowed:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/10733

But what about this case:

I've got a threaded app with a DRb-based remote debugging/control
interface. I want to stop all non-DRb threads when the user sends the
"stop" command. The the user (or other external process) can then send
more commands to the DRb interface and inspect stuff without those
threads running around like crazy. Then a later call to the DRb
interface can wakeup all the threads that got stopped.

I can't use Thread.critical, because the DRb interface has to stay awake
for the next request. None of the threads in the DRb group should be
stopped.

Setting the priority of the non-DRb threads very low doesn't seem to
work either--they keep running when the DRb threads are not running.

Any ideas? If Thread#stop is a bad idea, what is the right idea in this
case?

 

[David Vallner]

D=C5=88a Piatok 10 Febru=C3=A1r 2006 05:10 Joel VanderWerf nap=C3=ADsal:

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=
=20
than a real parallelism solution. What you're looking for sounds like a lat=
ch=20
construct that the user process opens and closes for the other threads. Bri=
ef=20
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=
=20
doable via Mutexes and Semaphores. (Do we have Semaphores in the core or=20
stdlib?)

David Vallner

 

[Joel VanderWerf]

D=C5=88a Piatok 10 Febru=C3=A1r 2006 05:10 Joel VanderWerf nap=C3=ADsal= :
=20
Letting threads directly play tricks on each other is more of a Q'n'D h= ack=20
than a real parallelism solution. What you're looking for sounds like a= latch=20
construct that the user process opens and closes for the other threads.= Brief=20
googling indicates you could use something called a read-write mutex / = lock.
=20
Maybe there's a ruby implementation out there already, if not, it shoul= d be=20
doable via Mutexes and Semaphores. (Do we have Semaphores in the core o= r=20
stdlib?)
=20
David Vallner
=20

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

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

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

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



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

 

[David Vallner]

D=C5=88a Piatok 10 Febru=C3=A1r 2006 21:29 Joel VanderWerf nap=C3=ADsal:

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 =3D Thread.new { Thread.stop; do_some_work }
prepare_for_th_to_run
th.wakeup

=46or some strange reason I thought you were using looping worker threads w=
ith=20
short execution time. Ah well.

David Vallner

 

[Joel VanderWerf]

D=C5=88a Piatok 10 Febru=C3=A1r 2006 21:29 Joel VanderWerf nap=C3=ADsal= :
=20
For some strange reason I thought you were using looping worker threads= with=20
short execution time. Ah well.

Well, some are fairly short lived, but those ones are fired off by some
"permathreads". In fact, the are so perma that they have a big rescue
clause with a retry (for StandardErrors) around everything they do.

Still wish I knew how to "freeze frame" all the threads, except the drb
threads that are inspecting them...

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