Here's a patch (this is against 3.1.2b). Untested. This replaces GIL with
with the APR lock.

--- src/mod_python.c.orig       Mon Sep 12 16:42:28 2005
+++ src/mod_python.c    Mon Sep 12 17:32:26 2005
@@ -31,7 +31,9 @@
* (In a Python dictionary) */
static PyObject * interpreters = NULL;

+#ifdef APR_HAS_THREAD
static apr_thread_mutex_t* interpreters_lock = 0;
+#endif

apr_pool_t *child_init_pool = NULL;

@@ -127,9 +129,8 @@
if (! name)
name = MAIN_INTERPRETER;

-#ifdef WITH_THREAD
+#ifdef APR_HAS_THREAD
 apr_thread_mutex_lock(interpreters_lock)
;
-    PyEval_AcquireLock();
#endif

if (!interpreters) {
@@ -156,8 +157,7 @@
idata = (interpreterdata *)PyCObject_AsVoidPtr(p);
}

-#ifdef WITH_THREAD
-    PyEval_ReleaseLock();
+#ifdef APR_HAS_THREAD
 apr_thread_mutex_unlock(interpreters_loc
k);
#endif

@@ -513,8 +513,10 @@
/* initialze the interpreter */
Py_Initialize();

-#ifdef WITH_THREAD
+#ifdef APR_HAS_THREAD
apr_thread_mutex_create(& interpreters_lock,APR_THREAD_MUTEX_UNNES
TED,p);
+#endif
+#ifdef WITH_THREAD
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif




On Mon, 12 Sep 2005, Gregory (Grisha) Trubetskoy wrote:

>
> Yep, this is getting a little hairy, but nothing we couldn't handle :-)
>
> I did a little more research. Basically, this started with Graham's patch
> that addressed a problem with modules being reimported (or something). Fro
m
> Graham's message:
> 
>
> So what Graham's patch does is create an APR lock (interpreters_lock) and
> wrap all the access to the dictionary with calls to apr_mutex_lock/unlock.
>
> I think the _real_ way to address this issue is to first find what is the
> problem with using the Python GIL to serialize access to the interpreters
> dictionary. Is this a Python bug, or are we not understanding GIL and usin
g
> it improperly?
>
> BUT, given that the above question may be complicated to answer, and that
> Graham's patch resolves the issue, another thought:
>
> If the APR lock works, what is the point of using the GIL in addition? Sho
uld
> we just use the APR-based lock alone? I.e., where we had (after Graham's
> patch):
>
> #ifdef WITH_THREAD
>       apr_thread_mutex_lock(interpreters_lock)
;
>      PyEval_AcquireLock();
> #endif
>
> we would use:
>
>  #ifdef APR_HAS_THREAD
>       apr_thread_mutex_lock(interpreters_lock)
;
>  #endif
>
> _without_ a call to PyEval_AcquireLock() at all.
>
> It should compile OK, and on platforms where APR has no thread support, li
ke
> you said, it's not an issue since no separate interpreters run in one proc
ess
> at the same time.
>
> Grisha
>
> On Mon, 12 Sep 2005, Nicolas Lehuen wrote:
> 
>

[ Post a follow-up to this message ]