[#62297] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap. — Eric Wong <normalperson@...>
nari@ruby-lang.org wrote:
7 messages
2014/05/02
[#62307] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— SASADA Koichi <ko1@...>
2014/05/03
(2014/05/03 4:41), Eric Wong wrote:
[#62402] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— Eric Wong <normalperson@...>
2014/05/05
SASADA Koichi <ko1@atdot.net> wrote:
[#62523] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — ko1@...
Issue #9632 has been updated by Koichi Sasada.
3 messages
2014/05/11
[#62556] doxygen (Re: Re: [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan) — Tanaka Akira <akr@...>
2014-05-11 8:50 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
3 messages
2014/05/13
[#62727] [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl — Eric Wong <normalperson@...>
rb_unlink_method_entry may cause old_me to be swept before the new
7 messages
2014/05/24
[#63039] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/10
Hi,
[#63077] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/10
SASADA Koichi <ko1@atdot.net> wrote:
[#63086] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/11
(2014/06/11 4:47), Eric Wong wrote:
[#63087] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/11
SASADA Koichi <ko1@atdot.net> wrote:
[#62862] [RFC] README.EXT: document rb_gc_register_mark_object — Eric Wong <normalperson@...>
Any comment on officially supporting this as part of the C API?
5 messages
2014/05/30
[ruby-core:62269] [ruby-trunk - Bug #6634] Deadlock with join and ConditionVariable
From:
nikkoara@...
Date:
2014-05-01 21:52:12 UTC
List:
ruby-core #62269
Issue #6634 has been updated by L Nikkoara. File t.rb added nhm tanveeer hossain khan wrote: > Hi there, > > I've faced similar problem with ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.1.0] (installed with rvm) Hey, I have the same problem. I took the test case you posted, reduced it further, and fiddled with the numbers of threads, etc. See attached. It crashed reliably for me, always right after launching it. If we are using Ruby threads the wrong way, please let us know. If not, could you please take another look at this issue and possibly reactivate it? Thanks. ---------------------------------------- Bug #6634: Deadlock with join and ConditionVariable https://bugs.ruby-lang.org/issues/6634#change-46432 * Author: meh. I don't care * Status: Rejected * Priority: Normal * Assignee: Yusuke Endoh * Category: core * Target version: 2.0.0 * ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux] * Backport: ---------------------------------------- I'm getting a fatal deadlock in one of my gems, it's a simple threadpool implementation. The library works both in Rubinius and JRuby, so I guess it's a bug. The gem is here: https://github.com/meh/ruby-threadpool The example that crashes is attached. Basically it raises a fatal deadlock if you join a thread and then call ConditionVariable#wait, I'm not 100% sure if the bug is in the ConditionVariable or what, all I know is that it happens in that situation and that it works on Rubinius and JRuby. ---Files-------------------------------- lol.rb (134 Bytes) noname (500 Bytes) reduced.rb (170 Bytes) lol2.rb (189 Bytes) thread_deadlock_error_test.rb (1.47 KB) t.rb (996 Bytes) -- https://bugs.ruby-lang.org/