From: "rklemme (Robert Klemme)" <shortcutter@...>
Date: 2012-04-12T16:49:02+09:00
Subject: [ruby-dev:45510] [ruby-trunk - Bug #5258] SizedQueueにBug #5195と同様のバグ


Issue #5258 has been updated by rklemme (Robert Klemme).


Hi again,

mame (Yusuke Endoh) wrote:
>  2012/4/11 rklemme (Robert Klemme) <shortcutter@googlemail.com>:
>  > nobu (Nobuyoshi Nakada) wrote:
>  >> It seems natural because the only thread is about to sleep.
>  >
>  > I would expect the thread to block indefinitely. Signalling an error here seems to try to be too smart.  Even in absence of other threads I can imagine conditions under which data is read from the queue (for example a signal handler).
>  
>  Interesting.  The error is indeed "false positive."  I did not noticed
>  signal handler.

I was lucky because I was just sensitized by Eric's recent article about signal handling in Ruby. :-)

>  But I'm not enthusiastic for your proposal.  It is too conservative.
>  It will increase too many "false negative."

You mean processes with no unblocked threads would go unnoticed?  What about the effort for JRuby and others to mimic this behavior?

>  > But even if an error is signaled here, it is certainly not a deadlock - for that you need at least two threads.  This is rather something like "only blocking thread is suspended (with no chance to wake up)".  Maybe that error should be controllable via a switch, e.g.
>  >
>  > Thread.single_thread_block_is_error = true # default false
>  
>  Do you have any practical case where you get bothered by the "false positive"?
>  If so, please open a feature request ticket with the use case.

Not at the moment.  The case I thought I had evaporated because it was a "silent thread death" case (i.e. Thread.abort_on_exception was at default - false - and the only other thread had silently died where I thought it would still be running).  But a better error message than "deadlock" as I have suggested above would have made me find the source of the issue much more quickly because it had hinted at the real problem.

I think I'll open a feature request to at least change the error message in case there is no other thread left.  Btw, is this really a deadlock detection or does the code only check for blocked threads?  From the code in check_deadlock_i() it is not totally obvious to me; I think the check only ensures at least one live thread - at least it does not seem to try to find the deadlock loop (as e.g. some relational databases do).

Kind regards

robert
----------------------------------------
Bug #5258: SizedQueueにBug #5195と同様のバグ
https://bugs.ruby-lang.org/issues/5258#change-25850

Author: Glass_saga (Masaki Matsushita)
Status: Assigned
Priority: Normal
Assignee: kosaki (Motohiro KOSAKI)
Category: lib
Target version: 2.0.0
ruby -v: ruby 1.9.4dev (2011-09-01 trunk 33157) [x86_64-linux]


=begin
[Bug #5195][ruby-dev:44400]と同様ですが、SizedQueue#pushでsleepしているthreadをwakeupさせると、SizedQueueの@queue_waitにそのthreadがpushされてしまいます。

 require 'thread'
 
 sq = SizedQueue.new(1)
 sq.push(0)
 
 t1 = Thread.start { sq.push(1) ; sleep }
 
 nil until t1.stop?
 t1.wakeup
 nil until t1.stop?
 
 t2 = Thread.start { sq.push(2) }
 
 nil until t1.stop? && t2.stop?
 
 p t1, t2
 sq.instance_eval{ p @queue_wait }
 
 3.times{ sq.pop }
 
 t2.join

上記のコードを実行すると、

 #<Thread:0x00000000b1a198 sleep>
 #<Thread:0x00000000b1a120 sleep>
 [#<Thread:0x00000000b1a198 sleep>, #<Thread:0x00000000b1a198 sleep>, #<Thread:0x00000000b1a120 sleep>]
 /usr/local/lib/ruby/1.9.1/thread.rb:185:in `sleep': deadlock detected (fatal)
        from /usr/local/lib/ruby/1.9.1/thread.rb:185:in `block in pop'
        from <internal:prelude>:10:in `synchronize'
        from /usr/local/lib/ruby/1.9.1/thread.rb:180:in `pop'
        from /usr/local/lib/ruby/1.9.1/thread.rb:324:in `pop'
        from sized_queue.rb:19:in `block in <main>'
        from sized_queue.rb:19:in `times'
        from sized_queue.rb:19:in `<main>'

となります。
場当たり的なものですが[Bug #5195][ruby-dev:44400]の時と同様なpatchを添付します。適用後もtest/thread/test_queue.rbをパスします。
 
=end


-- 
http://bugs.ruby-lang.org/