This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, neologix, nirai, pitrou, sbt, sdaoden, vstinner
Date 2011-08-31.21:02:04
SpamBayes Score 5.26925e-08
Marked as misclassified No
Message-id <>
In-reply-to <>
> Anyway, since my view does not seem to resonate with core developers I I'll
> give it a rest for now.

Well, the problem is that many views have been expressed in this
thread, which doesn't help getting a clear picture of what's needed to
make progress on this issue.
AFAIC, I think the following seems reasonable:
1) add an atfork module which provides a generic and
pthread_atfork-like mechanism to setup handlers that must be called
after fork (right now several modules use their own ad-hoc mechanism)
2) for multiprocessing, call exec() after fork() (issue #8713)
3) for buffered file objects locks, use the approach similar to the
patch I posted (reinit locks in the child process right after fork())

Does that sound reasonable?
Date User Action Args
2011-08-31 21:02:05neologixsetrecipients: + neologix, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, Giovanni.Bajo, sdaoden, sbt, avian
2011-08-31 21:02:04neologixlinkissue6721 messages
2011-08-31 21:02:04neologixcreate