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...).
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 ?)...
Regards,
Nicolas
2005/9/11, Jim Gallacher <[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]>>:
>>
>> 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
>>>
>>
>>
>
