[ruby-core:44209] Re: [ruby-trunk - Feature #5446][Feedback] at_fork callback API

"mame (Yusuke Endoh)" <[e-mail]> 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 :)