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
>>>
>>
>>
>
