Message143279
| 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.269252e-08 |
| Marked as misclassified |
No |
| Message-id |
<CAH_1eM2-UXj3ks783PY5SnupDMy5cF_PRnxZzwpffNRQ6WBasQ@mail.gmail.com> |
| In-reply-to |
<1314815143.08.0.52611461825.issue6721@psf.upfronthosting.co.za> |
| Content |
> 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? |
|