Message175975
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 succeeding.
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 PID.
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. |
|
Date |
User |
Action |
Args |
2012-11-20 00:52:12 | christian.heimes | set | recipients:
+ christian.heimes, twouters, gregory.p.smith, sbt |
2012-11-20 00:52:11 | christian.heimes | set | messageid: <1353372731.98.0.352773408024.issue16500@psf.upfronthosting.co.za> |
2012-11-20 00:52:11 | christian.heimes | link | issue16500 messages |
2012-11-20 00:52:11 | christian.heimes | create | |
|