Nicolas Lehuen wrote:
OK, so on a non-threaded Apache, we can suppose we will be using the
prefork MPM, so we don't need any code to support threading in
mod_python, then, right ?
Makes sense to me.
In this case instead of testing for WITH_THREAD in mod_python.c :
#ifdef WITH_THREAD
maybe we could test for WITH_THREAD and APR_HAS_THREADS :
#if APR_HAS_THREADS && defined(WITH_THREAD)
Right ? This would remove all threading-related code from mod_python
when only prefork is available or when Python isn't compiled to support
threads (I which case I wonder how it works in a threaded Apache...).
Seems reasonable. It compiles and passes the unit tests on debian.
I have given up using QEMU for now, minotaur is sufficient to make sure
mod_python builds on FreeBSD. Granted, it won't allow me to give any +1
since I cannot run the unit tests (or can I ?)...
I got FreeBSD running under QEMU, and the results are the same as on
minotaur. With the "#if APR_HAS_THREADS && defined(WITH_THREAD)" code
change, mod_python compiles but the final link step generates a warning
on both minotaur and qemu:
/usr/local/share/apache2/build/libtool --silent --mode=link cc -o
mod_python.la -rpath /usr/local/libexec/apache2 -module -avoid-version
hlistobject.lo hlist.lo filterobject.lo connobject.lo
serverobject.lo util.lo tableobject.lo requestobject.lo _apachemodule.lo
mod_python.lo -Wl,--export-dynamic -pthread -lm
/usr/local/lib/python2.4/config/libpython2.4.a -lutil -lm
*** Warning: Linking the shared library mod_python.la against the
*** static library /usr/local/lib/python2.4/config/libpython2.4.a is not
portable!
Likewise, the unit tests on both QEMU and minotaur fail.
On minotaur:
Syntax error on line 44 of
/home/jgallacher/tmp/mod_python/test/conf/test.conf:
Cannot load /home/jgallacher/tmp/mod_python/src/mod_python.so into
server: /home/jgallacher/tmp/mod_python/src/mod_python.so: Undefined
symbol "btowc"
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"
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
>>>
>>
>>
>
