On Dec 7, 2007, at 7:48 PM, James Gray 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.

a @ http://codeforpeople.com/
--
share your knowledge.  it's a way to achieve immortality.
h.h. the 14th dalai lama