[#45518] [ruby-trunk - Bug #6302][Open] irb で math-mode 中でも conf.math_mode に nil を代入すると math-mode を抜ける事ができる — "sho-h (Sho Hashimoto)" <sho-h@...>
5 messages
2012/04/15
[#45530] [ruby-trunk - Feature #6311][Open] memmem()によるrb_memsearch()の高速化 — "Glass_saga (Masaki Matsushita)" <glass.saga@...>
12 messages
2012/04/17
[#45533] Re: [ruby-cvs:42559] naruse:r35383 (trunk): Revert r35339-35343 because of no tests. — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
6 messages
2012/04/18
[#45534] Re: [ruby-cvs:42559] naruse:r35383 (trunk): Revert r35339-35343 because of no tests.
— Hiroshi Nakamura <nahi@...>
2012/04/18
(2012/04/19 2:02), Yukihiro Matsumoto wrote:
[#45535] Re: [ruby-cvs:42559] naruse:r35383 (trunk): Revert r35339-35343 because of no tests.
— "NARUSE, Yui" <naruse@...>
2012/04/19
2012年4月19日6:10 Hiroshi Nakamura <nahi@ruby-lang.org>:
[#45541] drb SSL test timeout — Tanaka Akira <akr@...>
Debian wheezy において、test_drbssl.rb のテストで 100秒の timeout にひっかかります。
10 messages
2012/04/21
[#45542] Re: drb SSL test timeout
— Masatoshi SEKI <m_seki@...>
2012/04/21
咳といいます。
[#45547] Re: drb SSL test timeout
— Tanaka Akira <akr@...>
2012/04/22
2012年4月22日6:52 Masatoshi SEKI <m_seki@mva.biglobe.ne.jp>:
[#45548] Re: drb SSL test timeout
— Masatoshi SEKI <m_seki@...>
2012/04/22
咳といいます。
[#45571] [ruby-trunk - Feature #6349][Open] Iconv の復活を希望します — "kyanagi (Kouhei Yanagita)" <redmine@...>
7 messages
2012/04/24
[#45572] Re: [ruby-dev:45571] [ruby-trunk - Feature #6349][Open] Iconv の復活を希望します
— "Martin J. Dürst" <duerst@...>
2012/04/24
やなぎたさん、こんにちは。
[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>