Shouldn't that be PYTHON_WITH_THREAD rather than MOD_PYTHON_WITH_THREAD?
Grisha
On Mon, 12 Sep 2005, Nicolas Lehuen wrote:
I've checked in a changeset wherein I define MOD_PYTHON_WITH_THREAD_SUPPORT
and use it everywhere WITH_THREAD was previously used. This should do the
trick ! Now if someone (like Jim) can give us his +1, that would be great.
Regards,
Nicolas
2005/9/12, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>:
Just wanted to add to this message that if Jim's version runs and tests
with the trick below (envvars is executed prior to apache start, but I
don't think the tests use it, so you'll probably just have to set this var
in the shell in which the tests are run), then this would be a solution
for all FreeBSD issues and we could roll a beta 3 which will have a great
change of being publicly released.
Grisha
On Mon, 12 Sep 2005, Gregory (Grisha) Trubetskoy wrote:
OK, found it. This should work on FreeBSD where Python is threaded and
Apache
is not.
[snip]
And, if you built apache without thread support, you may need to add the
following lines to $PREFIX/sbin/envvars:
LD_PRELOAD=/usr/lib/libc_r.so
export LD_PRELOAD
[snip]
On Mon, 12 Sep 2005, Gregory (Grisha) Trubetskoy wrote:
On Mon, 12 Sep 2005, Jim Gallacher wrote:
*** Warning: Linking the shared library mod_python.la against the
*** static library /usr/local/lib/python2.4/config/libpython2.4.a is
not
portable!
I think this was always there and its pretty harmless.
On qemu:
Syntax error on line 44 of
/usr/home/jim/tmp/mod_python/test/conf/test.conf:
Cannot load /usr/home/jim/tmp/mod_python/src/mod_python.so into
server:
/usr/home/jim/tmp/mod_python/src/mod_python.so: Undefined symbol
"pthread_attr_init"
This is because FreeBSD's libc comes in two versions - threaded and
non-threaded. If Python is linked against the threaded ones and Apache
against the non-thrreaded, then you get this problem. There is a simple
fix for this - you just cause Apache to start with threaded libs, but I
can't find any references to it right now and have to run off to a
meeting.
Grisha
It is quite possible I don't have things configured correctly on the
QEMU version and hence the different undefined symbol but it doesn't
really matter since it fails either way. I don't have time to
investigate further right now. I'll revisit this tonight.
Regards,
Jim
Regards,
Nicolas
#if APR_HAS_THREADS && defined(WITH_THREAD)
2005/9/11, Jim Gallacher <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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]>
<mailto: [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]>
<mailto:[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
