On Thu, Jul 16, 2009 at 1:08 PM, Thomas Wouters <thomas at python.org> wrote: > > Picking up a rather old discussion... We encountered this bug at Google and > I'm now "incentivized" to fix it. > > For a short recap: Python has an import lock that prevents more than one > thread from doing an import at any given time. However, unlike most of the > locks we have lying around, we don't clear that lock in the child after an > os.fork(). That means that doing an os.fork() during an import means the > child process can't do any other imports. It also means that doing an > os.fork() *while another thread is doing an import* means the child process > can't do any other imports. > > Since this three-year-old discussion we've added a couple of > post-fork-cleanups to CPython (the TLS, the threading module's idea of > active threads, see Modules/signalmodule.c:PyOS_AfterFork) and we already do > simply discard the memory for other locks held during fork (the GIL, see > Python/ceval.c:PyEval_ReInitThreads, and the TLS lock in > Python/thread.c:PyThread_ReInitTLS) -- but not so with the import lock, > except when the platform is AIX. I don't see any particular reason why we > aren't doing the same thing to the import lock that we do to the other > locks, on all platforms. It's a quick fix for a real problem (see > http://bugs.python.org/issue1590864 and > http://bugs.python.org/issue1404925 for two bugreports that seem to be > this very issue.) > +1. We were also affected by this bug, getting sporatic deadlocks in a multi-threaded program that fork()s subprocesses to do processing. It took a while to figure out what was going on. -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20090720/211660ed/attachment.htm>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4