Christian Heimes added the comment:

Meh! Exception handling takes all the fun of the API and is going to make it 
MUCH more complicated. pthread_atfork() ignores error handling for a good 
reason. It's going to be hard to get it right. :/

IFF we are going to walk the hard and rocky road of exception handling, then we 
are going to need at least four hooks and a register function that takres four 
callables as arguments: register(prepare, error, parent, child). Each prepare() 
call pushes an error handling onto a stack. In case of an exception in a 
prepare handler, the error stack is popped until all error handlers are called. 
This approach allows a prepare handler to actually prevent a fork() call from 

The parent and child hooks are always called no matter what. Exception are 
recorded and a warning is emitted when at least one hook fails. We might raise 
an exception but it has to be a special exception that ships information if 
fork() has succeeded, if the code runs in child or parent and about the child's 

I fear it's going to be *really* hard to get everything right.

Gregory made a good point, too. We can rely on pthread_atfork() as we are 
unable to predict how third party code is using fork(): "Take cover, dead locks 
ahead!" :) A cooperative design of the C API with three function is my 
preferred way, too. PyOS_AfterForkParent() should take an argument to signal a 
failed fork() call.


Python tracker <>
Python-bugs-list mailing list

Reply via email to