I’m not saying this is wrong, just clarifying what I am seeing. Is it
intended that at_exit() handlers are inherited by a fork()ed process?
For example:
at_exit { puts “Doing something important for #{Process.pid}.” }
fork
James Edward G. II
On Dec 7, 2007 12:33 PM, James G. [email protected] wrote:
I’m not saying this is wrong, just clarifying what I am seeing. Is it
intended that at_exit() handlers are inherited by a fork()ed process?
For example:at_exit { puts “Doing something important for #{Process.pid}.” }
fork
Makes sense to me.
#include<stdlib.h>
#include<sys/types.h>
#include<unistd.h>
#include<stdio.h>
static void handler() {
printf(“handler for pid %d\n”,getpid());
}
int main() {
atexit(handler);
if(fork()) wait(0);
return 0;
}
-Adam
Hi,
In message “Re: at_exit() Inherited Across fork()”
on Sat, 8 Dec 2007 05:33:41 +0900, James G.
[email protected] writes:
|I’m not saying this is wrong, just clarifying what I am seeing. Is it
|intended that at_exit() handlers are inherited by a fork()ed process?
Yes. Is it a problem?
matz.
On Dec 7, 2007, at 1:33 PM, James G. wrote:
I’m not saying this is wrong, just clarifying what I am seeing. Is
it intended that at_exit() handlers are inherited by a fork()ed
process? For example:at_exit { puts “Doing something important for #{Process.pid}.” }
forkJames Edward G. II
it’s expected, and easy to get around if you want:
fork do
at_exit{ exit! }
end
you just have to do it right up front in order to dis-own the
handlers from the parent - i do this is slave.rb or open4.rb - can’t
recall which offhand.
cheers.
On Dec 7, 2007, at 7:19 PM, Yukihiro M. wrote:
Yes. Is it a problem?
Not really. I think I understand why it is.
It just seems a little counter intuitive that at_exit() does anything
outside of the current process. I’m having a hard time imagining when
I would want it to.
Thanks for confirming though.
James Edward G. II
On Dec 7, 2007, at 7:26 PM, ara.t.howard wrote:
James Edward G. II
recall which offhand.
This is pretty much how we solved it. We used exit!() in the fork()ed
process.
I guess it just kind of feels like the scripting language should be
doing something more clever for us here so we don’t have to do this
kind of stuff though.
James Edward G. II
On Dec 7, 2007, at 7:48 PM, James G. wrote:
This is pretty much how we solved it. We used exit!() in the fork()
ed process.
you don’t want to do that really - any at_exit handlers in the child
will not be called. for instance, if you are using tmpfiles they
will not be cleaned up.
I guess it just kind of feels like the scripting language should be
doing something more clever for us here so we don’t have to do this
kind of stuff though.
i personally prefer ruby to violate c semantics as little as possible
but i can see it being surprising too. so long as we can easily
obtain both behaviors it hardly matters…
btw. another approach is to for the children before setting up the
exit handlers - you just have to arrange for them to hang around
waiting to do something, reading the cmd to execute from a pipe to
the parent for example.
one other note - when i write rq i had bizarre issues caused by
forking from inside an sqlite transaction (virtually no db supports
this actually) - what i ended up doing is to create a drb process
that is owned by the parent. the parent then asks this drb process
to fork on it’s behalf to do something. the interface supports
Process.wait, etc, but the forking is actually occuring in child
that’s creating grandchildren. by using this approach the drb
process can be setup early before the initial process has had a
chance to setup at_exit handlers and also before it’s gotten big.
cheers.
James G. wrote:
I guess it just kind of feels like the scripting language should be
doing something more clever for us here so we don’t have to do this kind
of stuff though.
I’d rather that ruby mirror the C API, and make it easy to add your own
behavior on top of that.
What about something like this?
module Kernel
def at_exit_in_this_process(&handler)
unless $at_exit_in_this_process
$at_exit_in_this_process = Hash.new{|h,k| h[k]=[]}
at_exit do
$at_exit_in_this_process[Process.pid].reverse_each do |hdlr|
hdlr.call
end
end
end
$at_exit_in_this_process[Process.pid] << handler
end
end
at_exit_in_this_process {p 1}
fork do
at_exit_in_this_process {p 2}
end
Process.wait
On Dec 7, 2007, at 10:47 PM, Joel VanderWerf wrote:
James G. wrote:
I guess it just kind of feels like the scripting language should
be doing something more clever for us here so we don’t have to do
this kind of stuff though.I’d rather that ruby mirror the C API, and make it easy to add your
own behavior on top of that.
My quick read of <The Open Group Base Specifications Issue 6
functions/atexit.html> suggests
that atexit handlers are only called when exit() is called or main()
returns. So atexit()
handlers are not called before a fork in the C/POSIX world.
If Ruby’s at_exit() behavior differs from this, I’m not seeing it.
Gary W.
Gary W. wrote:
My quick read of
http://www.opengroup.org/onlinepubs/009695399/functions/atexit.html
suggests
that atexit handlers are only called when exit() is called or main()
returns. So atexit()
handlers are not called before a fork in the C/POSIX world.If Ruby’s at_exit() behavior differs from this, I’m not seeing it.
Gary W.
What I meant to say was, I’d rather that ruby continue to mirror the C
API… I’m a ruby conservative 