From: Eric Wong Date: 2012-04-09T13:34:03+09:00 Subject: [ruby-core:44209] Re: [ruby-trunk - Feature #5446][Feedback] at_fork callback API "mame (Yusuke Endoh)" wrote: > Do you still want this feature? Yes, but lower priority. I think default to IO#close_on_exec=true for 2.0.0 makes this less important. > If so, could you answer kosaki's comment? kosaki wrote: > As you know, we can only call asynchronous-signal-safe function > between fork and exec when the process is multi threaded. but ruby > code invocation definitely need to use malloc which not > async-signal-safe. so, it's pretty hard to implement. Am I missing > something? I can't edit the existing ticket, but I think _only_ Kernel#fork should be touched. Methods that call exec after fork will already get things cleaned up from close_on_exec. If there is a _Ruby_ call to exec, then we already have a chance to use non-async-signal safe code. It could be implemented in pure Ruby, even. This is a prototype (using xfork name) intead: ATFORK = { :prepare => [ lambda { puts ":prepare in #$$" } ], :parent => [ lambda { puts ":parent in #$$" } ], :child => [ lambda { puts ":child in #$$" } ], } def xfork ATFORK[:prepare].each { |code| code.call } if block_given? pid = fork do ATFORK[:child].each { |code| code.call } yield end ATFORK[:parent].each { |code| code.call } else case pid = fork when nil ATFORK[:child].each { |code| code.call } when Integer ATFORK[:parent].each { |code| code.call } end end pid end I haven't thought of an API to manipulate the ATFORK arrays with. I don't want to emulate pthread_atfork() directly, it's too cumbersome for Ruby. Perhaps: at_fork(:prepare) { ... } at_fork(:child) { ... } at_fork(:parent) { ... } > OT: We noticed and surprised at your ID (normalperson) at the recent > developers' meeting in Akihabara. Clearly, you are greatperson :-) I don't think of myself as great. But if others think I'm great, they should try to be like me, then we'll all be normal :)