Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

2005-09-11 Thread Nicolas Lehuen 
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.

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,
Nicolas2005/9/10, Jim Gallacher <[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>

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

2005-09-11 Thread Nicolas Lehuen 
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.

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.

Regards,
Nicolas2005/9/11, Nicolas Lehuen <[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.

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,
Nicolas2005/9/10, Jim Gallacher <[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>

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

2005-09-11 Thread Jim Gallacher 

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


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
.

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

 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

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

2005-09-11 Thread Jim Gallacher 

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


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
.

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


 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