>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> unlikely to be Python's fault. Everyone pursuing the other
TP> "fork bug" please note that test_fork1 doesn't import threading
TP> or use any mutexes -- it just spawns threads, forks once, and
TP> .sleeps() a lot.
I don't think the "other" "fork bug" uses any more thread gimmicks
than the bug you're considering. The test script that Neil posted did
use the threading module, but it works just as well with the thread
module. It only uses start_new_thread.
The big difference between the two bugs is that the one Neil posted
results in deadlock rather than a segfault. So they may well be
completely different.
For both bugs, though, a mutex and a condition variable are being use:
The interpreter lock is being acquired and released in both cases.
My current theory is that Python isn't dealing with the interpreter
lock correctly across a fork. If some thread other than the one
calling fork holds the interpreter lock mutex, the lock will be held
forever in the child thread. If the child thread isn't making
progress, the parent thread won't make progress either.
Jeremy
Here's a simplified test case:
import os
import thread
def f():
while 1:
if os.fork() == 0:
print "%s %s" % (thread.get_ident(), os.getpid())
os._exit(0)
os.wait()
thread.start_new_thread(f, ())
thread.start_new_thread(f, ())
f()
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