[#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:62372] [ruby-trunk - Bug #6634] Deadlock with join and ConditionVariable
From:
kosaki.motohiro@...
Date:
2014-05-04 23:31:13 UTC
List:
ruby-core #62372
Issue #6634 has been updated by Motohiro KOSAKI. On Sat, May 3, 2014 at 8:45 AM, <nikkoara@hates.ms> wrote: > Issue #6634 has been updated by L Nicoara. > > > L Nicoara wrote: >> 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. >> > > For the record, the test case is malformed. Bummer. I think the one I based it on (from khan) is malformed as well. My apologies if you spent time on it. NP :) ---------------------------------------- Bug #6634: Deadlock with join and ConditionVariable https://bugs.ruby-lang.org/issues/6634#change-46531 * 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/