2000-02-25 15:25:05 -04:00
|
|
|
"""This test checks for correct fork() behavior.
|
|
|
|
"""
|
|
|
|
|
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.
2009-09-16 16:55:54 -03:00
|
|
|
import errno
|
|
|
|
import imp
|
2006-03-20 02:30:08 -04:00
|
|
|
import os
|
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.
2009-09-16 16:55:54 -03:00
|
|
|
import signal
|
|
|
|
import sys
|
2006-07-07 03:03:15 -03:00
|
|
|
import time
|
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.
2009-09-16 16:55:54 -03:00
|
|
|
import threading
|
|
|
|
|
2006-03-20 02:30:08 -04:00
|
|
|
from test.fork_wait import ForkWait
|
2009-03-30 20:05:48 -03:00
|
|
|
from test.test_support import run_unittest, reap_children, get_attribute
|
2009-03-30 16:04:00 -03:00
|
|
|
|
|
|
|
#Skip test if fork does not exist.
|
2009-03-30 20:05:48 -03:00
|
|
|
get_attribute(os, 'fork')
|
2000-02-25 15:25:05 -04:00
|
|
|
|
2000-05-03 21:36:42 -03:00
|
|
|
|
2006-03-20 02:30:08 -04:00
|
|
|
class ForkTest(ForkWait):
|
|
|
|
def wait_impl(self, cpid):
|
2006-07-07 03:03:15 -03:00
|
|
|
for i in range(10):
|
|
|
|
# waitpid() shouldn't hang, but some of the buildbots seem to hang
|
|
|
|
# in the forking tests. This is an attempt to fix the problem.
|
|
|
|
spid, status = os.waitpid(cpid, os.WNOHANG)
|
|
|
|
if spid == cpid:
|
|
|
|
break
|
|
|
|
time.sleep(1.0)
|
|
|
|
|
2006-03-20 02:30:08 -04:00
|
|
|
self.assertEqual(spid, cpid)
|
|
|
|
self.assertEqual(status, 0, "cause = %d, exit = %d" % (status&0xff, status>>8))
|
|
|
|
|
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.
2009-09-16 16:55:54 -03:00
|
|
|
def test_import_lock_fork(self):
|
|
|
|
import_started = threading.Event()
|
|
|
|
fake_module_name = "fake test module"
|
|
|
|
partial_module = "partial"
|
|
|
|
complete_module = "complete"
|
|
|
|
def importer():
|
|
|
|
imp.acquire_lock()
|
|
|
|
sys.modules[fake_module_name] = partial_module
|
|
|
|
import_started.set()
|
|
|
|
time.sleep(0.01) # Give the other thread time to try and acquire.
|
|
|
|
sys.modules[fake_module_name] = complete_module
|
|
|
|
imp.release_lock()
|
|
|
|
t = threading.Thread(target=importer)
|
|
|
|
t.start()
|
|
|
|
import_started.wait()
|
|
|
|
pid = os.fork()
|
|
|
|
try:
|
|
|
|
if not pid:
|
|
|
|
m = __import__(fake_module_name)
|
|
|
|
if m == complete_module:
|
|
|
|
os._exit(0)
|
|
|
|
else:
|
|
|
|
os._exit(1)
|
|
|
|
else:
|
|
|
|
t.join()
|
|
|
|
# Exitcode 1 means the child got a partial module (bad.) No
|
|
|
|
# exitcode (but a hang, which manifests as 'got pid 0')
|
|
|
|
# means the child deadlocked (also bad.)
|
|
|
|
self.wait_impl(pid)
|
|
|
|
finally:
|
|
|
|
try:
|
|
|
|
os.kill(pid, signal.SIGKILL)
|
|
|
|
except OSError:
|
|
|
|
pass
|
|
|
|
|
2006-03-20 02:30:08 -04:00
|
|
|
def test_main():
|
|
|
|
run_unittest(ForkTest)
|
2006-06-29 01:10:08 -03:00
|
|
|
reap_children()
|
2000-02-25 15:25:05 -04:00
|
|
|
|
2006-03-20 02:30:08 -04:00
|
|
|
if __name__ == "__main__":
|
|
|
|
test_main()
|