Author christian.heimes
Recipients christian.heimes, gregory.p.smith, sbt, twouters
Date 2012-11-20.00:52:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1353372731.98.0.352773408024.issue16500@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-11-20 00:52:12christian.heimessetrecipients: + christian.heimes, twouters, gregory.p.smith, sbt
2012-11-20 00:52:11christian.heimessetmessageid: <1353372731.98.0.352773408024.issue16500@psf.upfronthosting.co.za>
2012-11-20 00:52:11christian.heimeslinkissue16500 messages
2012-11-20 00:52:11christian.heimescreate