Issue #6288 has been updated by mame (Yusuke Endoh).

Status changed from Feedback to Assigned
Assignee set to mame (Yusuke Endoh)

Hello,

2012/4/14 rklemme (Robert Klemme) <shortcutter / googlemail.com>:
> mame (Yusuke Endoh) wrote:
>> Is "possible deadlock detected" better?
>
> If I understand properly what the deadlock check does (see also #5258) it merely verifies that there is at least one thread left which could wake up this thread. ??So I'd rather have something like "No live threads left. Deadlock?", but then again my understanding of the code in question is not too thorough.

Looks reasonable to me.  I'll commit unless there is no objection.


>> Please elaborate "a more complex scenario" with small example.
>
> $ ruby19 -r thread -e 'q=SizedQueue.new(100);r=Thread.new {until (x=q.deq).nil?; raise "SilentError";end};1000.times {|i| q.enq i};q.enq nil'
> /opt/lib/ruby/1.9.1/thread.rb:301:in `sleep': deadlock detected (fatal)
> ?? ?? ?? ??from /opt/lib/ruby/1.9.1/thread.rb:301:in `block in push'
> ?? ?? ?? ??from <internal:prelude>:10:in `synchronize'
> ?? ?? ?? ??from /opt/lib/ruby/1.9.1/thread.rb:297:in `push'
> ?? ?? ?? ??from -e:1:in `block in <main>'
> ?? ?? ?? ??from -e:1:in `times'
> ?? ?? ?? ??from -e:1:in `<main>'
>
> Basically what happens is that the reader thread silently dies as you can see if you set Thread.abort_on_exception:

It does not make sense.  Did you write the code to wait forever?
If so, you should write "sleep" simply.  If not, your code is
actually "deadlocked", in a common sense.

Why didn't you insist that Thread.abort_on_exception be true by
default?  I can't understand why you blame deadlock detection.

-- 
Yusuke Endoh <mame / tsg.ne.jp>
----------------------------------------
Bug #6288: Change error message for thread block to be less misleading
https://bugs.ruby-lang.org/issues/6288#change-25892

Author: rklemme (Robert Klemme)
Status: Assigned
Priority: Normal
Assignee: mame (Yusuke Endoh)
Category: core
Target version: 
ruby -v: ruby 1.9.3p125 (2012-02-16) [i386-cygwin]


Test case:

11:50:07 ~$ ruby19 -r thread -e 'q=SizedQueue.new 10;1_000_000.times {|i| p i;q.enq i}'
0
1
2
3
4
5
6
7
8
9
10
/opt/lib/ruby/1.9.1/thread.rb:301:in `sleep': deadlock detected (fatal)
        from /opt/lib/ruby/1.9.1/thread.rb:301:in `block in push'
        from <internal:prelude>:10:in `synchronize'
        from /opt/lib/ruby/1.9.1/thread.rb:297:in `push'
        from -e:1:in `block in <main>'
        from -e:1:in `times'
        from -e:1:in `<main>'


This is not a deadlock, but there is no other thread which could wake up main thread.  Deadlock is misleading because in a more complex scenario where I had the error initially it wasn't obvious that the other thread had died and I looked for the wrong error in my code.


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