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 <rep...@bugs.python.org>
Python-bugs-list mailing list