[#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:62590] Re: [ruby-trunk - Bug #9835] IGNORE signal handler has possible race condition in Ruby 2.1.2
From:
Eric Wong <normalperson@...>
Date:
2014-05-14 19:28:00 UTC
List:
ruby-core #62590
It looks like a race condition in your code. You were lucky to not hit
it in 1.8.7 or with a different use of trap (because execution speeds
may be different different).
parent execution timeline
-----------------------------+
trap(USR1, show_children) |
|
fork ------------------------+-- child execution timeline -----
|
*** kill(USR1, -getpgid($$)) | trap(USR1, IGNORE)
|
Once you fork, parent and child run in parallel. So the order of
execution where '***' is highlighted is outside your control.
So to ensure your child ignores properly, you must setup the ignore
handler before forking. There will always be a moment in time where
the parent and child will have the same signal handler.
You also do not want to a signal in the parent which arrive immediately
before or after the fork, either. So I suggest something like the
following to defer signals in the parent:
# note: this count nals in general) is racy
usr1_queue = []
show_children = trap("USR1") { usr1_queue << nil } # defer signals
pid = fork
if pid # parent
trap("USR1", show_children) # restore immediate handling
# process deferred signals
usr1_queue.each { show_children.call }
usr1_queue.clear
...
else # child
trap("USR1", "IGNORE")
# do nothing with usr1_queue here, implicitly ignored
...
end