[#45530] [ruby-trunk - Feature #6311][Open] memmem()によるrb_memsearch()の高速化 — "Glass_saga (Masaki Matsushita)" <glass.saga@...>

12 messages 2012/04/17

[#45554] [ruby-trunk - Bug #6344][Open] 1.9.3 p125, p194 ruby causes SEGV with test_massign.rb on ppc/ppc64 — "mtasaka (Mamoru Tasaka)" <mtasaka@...>

14 messages 2012/04/23

[ruby-dev:45508] Re: [ruby-trunk - Bug #5258] SizedQueueにBug #5195と同様のバグ

From: Yusuke Endoh <mame@...>
Date: 2012-04-11 15:24:04 UTC
List: ruby-dev #45508
Hello,

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. ven 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.

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


> But even if an error is signaled here, it is certainly not a deadlock - for that you need at least two threads. his is rather something like "only blocking thread is suspended (with no chance to wake up)". aybe 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.

-- 
Yusuke Endoh <mame@tsg.ne.jp>

In This Thread