svn+ssh://pythondev@svn.python.org/python/trunk

........
  r74841 | thomas.wouters | 2009-09-16 12:55:54 -0700 (Wed, 16 Sep 2009) | 23 lines


  Fix issue #1590864, multiple threads and fork() can cause deadlocks, by
  acquiring the import lock around fork() calls. This prevents other threads
  from having that lock while the fork happens, and is the recommended way of
  dealing with such issues. There are two other locks we care about, the GIL
  and the Thread Local Storage lock. The GIL is obviously held when calling
  Python functions like os.fork(), and the TLS lock is explicitly reallocated
  instead, while also deleting now-orphaned TLS data.

  This only fixes calls to os.fork(), not extension modules or embedding
  programs calling C's fork() directly. Solving that requires a new set of API
  functions, and possibly a rewrite of the Python/thread_*.c mess. Add a
  warning explaining the problem to the documentation in the mean time.

  This also changes behaviour a little on AIX. Before, AIX (but only AIX) was
  getting the import lock reallocated, seemingly to avoid this very same
  problem. This is not the right approach, because the import lock is a
  re-entrant one, and reallocating would do the wrong thing when forking while
  holding the import lock.

  Will backport to 2.6, minus the tiny AIX behaviour change.
........

The hppa ubuntu box sometimes hangs forever in these tests.  My guess
is that the wait is failing for some reason.  Use WNOHANG, so we won't
wait until the buildbot kills the test suite.

I haven't been able to reproduce the failure, so I'm not sure if
this will help or not.  Hopefully, this change will cause the test
to fail, rather than hang.  That will be better since we will get
the rest of the test results.  It may also help us debug the real problem.

*** The reason this originally failed was because there were many
zombie children outstanding before rev 47158 cleaned them up.
There are still hangs in test_subprocess that need to be addressed,
but that will take more work.  This should close some holes.

be called at the end of each test that spawns children (perhaps it
should be called from regrtest instead?).  This will hopefully prevent
some of the unexplained failures in the buildbots (hppa and alpha)
during tests that spawn children.  The problems were not reproducible.
There were many zombies that remained at the end of several tests.
In the worst case, this shouldn't cause any more problems,
though it may not help either.  Time will tell.

is that the wait is failing for some reason.  Use WNOHANG, so we won't
wait until the buildbot kills the test suite.

I haven't been able to reproduce the failure, so I'm not sure if
this will help or not.  Hopefully, this change will cause the test
to fail, rather than hang.  That will be better since we will get
the rest of the test results.  It may also help us debug the real problem.

This was a fair amount of rework of the patch.  Refactored test_fork1 so it
could be reused by the new tests for wait3/4.  Also made them into new style
unittests (derive from unittest.TestCase).

Tested for not breaking builds on Linux.

and replaces them with a new API verify(). As a result the regression
suite will also perform its tests in optimization mode.

Written by Marc-Andre Lemburg. Copyright assigned to Guido van Rossum.

Minor updates for BeOS R5.

Use of OSError in test.test_fork1 changed to TestSkipped, with corresponding
change in BeOS/README (by Fred).

This closes SourceForge patch #100978.

to signify a test that should be marked as 'skipped' rather than 'failed'.
Also 'document' it, in README.

the change to regrtest.py to unload all newly imported modules did
something bad to the threads -- and I realized that they would never
stop!

Instead of assuming that the number process ids of the threads is the
same as the process id of the controlling process, use a copy of the
dictionary and check for changes in the process ids of the threads
from the thread's process ids in the parent process.  This makes the
test make more sense on systems which assign a new pid to each thread
(i.e., Linux).

This doesn't fix the other problems evident with this test on Linux.

Only the main thread should survive in the child after a fork().