| Gregory (Grisha) Trubetskoy 2005-09-12, 5:52 pm |
|
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). From
> 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 using
> 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? Should
> 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, like
> you said, it's not an issue since no separate interpreters run in one process
> at the same time.
>
> Grisha
>
> On Mon, 12 Sep 2005, Nicolas Lehuen wrote:
>
>
|