FYI, I found the following note in the INSTALL file in the apache source:
* If you are building on FreeBSD, be aware that threads will
be disabled and the prefork MPM will be used by default,
as threads do not work well with Apache on FreeBSD. If
you wish to try a threaded Apache on FreeBSD anyway, use
"./configure --enable-threads".
I'm also setting up FreeBSD under QEMU... so far so good, but installing
anything using ports is really slow. QEMU's performance here is just
killing me. I guess I should have read the manual first and used the
binary packages for the software I wanted to install. :-(
Regards,
Jim
Jim Gallacher wrote:
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
