Nicolas Lehuen wrote:
OK, I've checked in a version that compiles both on at least Win32 and
FreeBSD. I'm just testing if APR_HAS_THREAD is defined and only include
the apr_thread_mutex_lock and unlock calls if it is defined.
Compiles a passes unit tests on Linux Debian sid with mpm-prefork.
Now, on minotaur, APR_HAS_THREAD is defined as 0. Does this mean that
Apache is not configured for threading ? Can we assume that we are in
the prefork model if APR_HAS_THREAD==0, so that we can skip all the
locking code ? Because that's what we do right now.
On Debian sid with apache2.0.54 mpm-prefork, APR_HAS_THREAD == 1.
Jim
Regards,
Nicolas
2005/9/11, Nicolas Lehuen <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Yes, this new code is something I commited on the 29/12/2004 (I used
the "blame" function of TortoiseSVN for that). It was a patch by
Graham to fix MODPYTHON-2
<http://issues.apache.org/jira/browse/MODPYTHON-2>.
The problem is not in the patch, but rather in the fact that APR
seems configured without the thread support while Python is
configured with thread support. mod_python.c assumes that is
WITH_THREAD is defined, then the APR mutex functions are available,
which is wrong. Maybe we should test for APR_HAS_THREADS instead ?
In that case, won't this cause any problems on threaded platforms ?
I don't know if this is a problem specific to minotaur or to all
version of FreeBSD. I'm currently downloading the ISOs of FreeBSD
and I'll try using QEMU to run a FreeBSD setup on my computer, but
that will be long and troublesome. If someone has more clue on this
issue, feel free to tell us :).
Regards,
Nicolas
2005/9/10, Jim Gallacher <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
I'm stubling around in the dark here, but maybe this will create a
spark
of an idea. I took a diff of mod_python.c from 3.1.4 and 3.2.1b and
isolated the lines which correspond to the compilation error.
Compiler messages
-----------------
mod_python.c:34: error: syntax error before '*' token
mod_python.c:34: warning: type defaults to `int' in declaration of
`interpreters_lock'
mod_python.c:34: warning: data definition has no type or storage class
mod_python.c: In function `get_interpreter':
mod_python.c:131: warning: implicit declaration of function
`apr_thread_mutex_lock'
mod_python.c:161: warning: implicit declaration of function
`apr_thread_mutex_unlock'
mod_python.c: In function `python_init':
mod_python.c:517: warning: implicit declaration of function
`apr_thread_mutex_create'
mod_python.c:517: error: `APR_THREAD_MUTEX_UNNESTED' undeclared (first
use in this function)
Diff output
-----------
I've only copied the diff chunks which correspond to the complier
errors
mentioned above.
--- mod_python-3.1.4/src/mod_python.c Sat Jan 29 13:25:28 2005
+++ mod_python-3.2.1b/src/mod_python.c Tue Sep 6 17:11:03 2005
@@ -31,6 +31,8 @@
* (In a Python dictionary) */
static PyObject * interpreters = NULL;
+static apr_thread_mutex_t* interpreters_lock = 0;
+
apr_pool_t *child_init_pool = NULL;
... snip ...
@@ -124,11 +128,15 @@
name = MAIN_INTERPRETER;
#ifdef WITH_THREAD
+ apr_thread_mutex_lock(interpreters_lock);
PyEval_AcquireLock();
#endif
... snip ...
@@ -149,6 +158,7 @@
#ifdef WITH_THREAD
PyEval_ReleaseLock();
+ apr_thread_mutex_unlock(interpreters_lock);
#endif
... snip ...
@@ -490,13 +506,15 @@
}
/* initialize global Python interpreter if necessary */
- if (! Py_IsInitialized())
+ if (initialized == 0 || !Py_IsInitialized())
{
-
+ initialized = 1;
+
/* initialze the interpreter */
Py_Initialize();
#ifdef WITH_THREAD
+
apr_thread_mutex_create(&interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p);
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
So it would seem that the code causing the compile problems is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h the typedef for
apr_thread_mutex_t is wrapped by #if APR_HAS_THREADS / #endif.
Looking at the apache source in srclib/apr/locks/unix/thread_mutex.c,
everything is also enclosed by #if APR_HAS_THREADS / #endif.
eg, apr_thread_mutex_create, apr_thread_mutex_lock and
apr_thread_mutex_unlock.
Hopefully this will give someone a clue as to what may be going on
here
with FreeBSD.
Regards,
Jim
