Bill Kelly wrote:
> Hi,
> 
> I'm experiencing strange behavior in a Ruby app doing
> multithreaded I/O, and I seem to have narrowed it down
> to my using a timeout { } block around a condition 
> variable wait.  E.g.
> 
>   timeout(1.0) { @condition_variable.wait(@mutex) }
> 
> The whole program is currently still a bit too large
> to post, but now that I'm able to reproduce the problem
> pretty reliably, I think I could narrow it down to just
> a few lines if need be.  But first, I wanted to ask if
> it's even *supposed* to be reasonable to use timeout
> in this fashion.
> 
> If it's supposed to be OK to do a timeout around a
> condition variable wait, then, I'll be happy to try
> to narrow it down to a few lines of code that reproduce
> the problem I'm seeing.  (I'm seeing threads not being
> awakened when signalled.  Note that these are 
> completely different threads with different condition
> variables and mutexes than the one the timeout applies to.)
> 
> If doing a timeout isn't OK around a condition variable
> wait, then, I'd like to ask what alternatives are
> recommended?  I would very much like to have a timeout
> somehow on a condition variable wait.

Probably wrong, but... when the timeout happens, a TimeoutError is 
raised in the thread that called #timeout. If you don't rescue this 
error and do something with it, the thread dies (silently, unless 
Thread.abort_on_exception is enabled). This may be why threads that have 
called #timeout later become unresponsive. (Or maybe I'm totally wrong 
and you are catching the TimeoutError somewhere and the problem is 
something else.)

For example, the following code simply prints "main done". If you 
uncomment the two lines, you also get "thread done".

   require 'timeout'

   Thread.new do
     begin
       timeout(0.2) do
         sleep
       end
   #  rescue Exception => e
   #    p e
     end
     puts "thread done"
   end

   sleep 0.4
   puts "main done"

HTH.