[Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...)
Thu, 27 Jul 2000 19:08:33 -0400 (EDT)
>>>>> "TP" == Tim Peters <email@example.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
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.
Here's a simplified test case:
if os.fork() == 0:
print "%s %s" % (thread.get_ident(), os.getpid())