[Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...)

[Jeremy Hylton]

>>>>> "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()