Merged revisions 75246 via svnmerge from

svn+ssh://pythondev@svn.python.org/python/branches/py3k

................
  r75246 | benjamin.peterson | 2009-10-04 15:32:25 -0500 (Sun, 04 Oct 2009) | 29 lines

  Merged revisions 74841 via svnmerge from
  svn+ssh://pythondev@svn.python.org/python/trunk

  ........
    r74841 | thomas.wouters | 2009-09-16 14:55:54 -0500 (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.
  ........
................

1 files changed, 12 insertions, 19 deletions

diff --git a/Python/import.c b/Python/import.c
index e143322..1129a7f 100644
--- a/Python/import.c
+++ b/Python/import.c
@@ -261,8 +261,8 @@ static PyThread_type_lock import_lock = 0;
 static long import_lock_thread = -1;
 static int import_lock_level = 0;
 
-static void
-lock_import(void)
+void
+_PyImport_AcquireLock(void)
 {
 	long me = PyThread_get_thread_ident();
 	if (me == -1)
@@ -286,8 +286,8 @@ lock_import(void)
 	import_lock_level = 1;
 }
 
-static int
-unlock_import(void)
+int
+_PyImport_ReleaseLock(void)
 {
 	long me = PyThread_get_thread_ident();
 	if (me == -1 || import_lock == NULL)
@@ -302,23 +302,16 @@ unlock_import(void)
 	return 1;
 }
 
-/* This function is called from PyOS_AfterFork to ensure that newly
-   created child processes do not share locks with the parent. */
+/* This function used to be called from PyOS_AfterFork to ensure that newly
+   created child processes do not share locks with the parent, but for some
+   reason only on AIX systems. Instead of re-initializing the lock, we now
+   acquire the import lock around fork() calls. */
 
 void
 _PyImport_ReInitLock(void)
 {
-#ifdef _AIX
-	if (import_lock != NULL)
-		import_lock = PyThread_allocate_lock();
-#endif
 }
 
-#else
-
-#define lock_import()
-#define unlock_import() 0
-
 #endif
 
 static PyObject *
@@ -335,7 +328,7 @@ static PyObject *
 imp_acquire_lock(PyObject *self, PyObject *noargs)
 {
 #ifdef WITH_THREAD
-	lock_import();
+	_PyImport_AcquireLock();
 #endif
 	Py_INCREF(Py_None);
 	return Py_None;
@@ -345,7 +338,7 @@ static PyObject *
 imp_release_lock(PyObject *self, PyObject *noargs)
 {
 #ifdef WITH_THREAD
-	if (unlock_import() < 0) {
+	if (_PyImport_ReleaseLock() < 0) {
 		PyErr_SetString(PyExc_RuntimeError,
 				"not holding the import lock");
 		return NULL;
@@ -2200,9 +2193,9 @@ PyImport_ImportModuleLevel(char *name, PyObject *globals, PyObject *locals,
 			 PyObject *fromlist, int level)
 {
 	PyObject *result;
-	lock_import();
+	_PyImport_AcquireLock();
 	result = import_module_level(name, globals, locals, fromlist, level);
-	if (unlock_import() < 0) {
+	if (_PyImport_ReleaseLock() < 0) {
 		Py_XDECREF(result);
 		PyErr_SetString(PyExc_RuntimeError,
 				"not holding the import lock");