OK, I found the problem. The LockFile line is commented out in test.py
which causes Apache to try to create the lock in the default location in
/var/run.
http://svn.apache.org/viewcvs.cgi/httpd/mod_python/trunk/test/test.py?rev=125771r1=106619r2=125771
So the question is - can we just put
I'd keep the patch nonetheless - I think this is how it should be.
Grisha
On Mon, 12 Sep 2005, Jim Gallacher wrote:
-1 for this patch. Actually, the patch itself is fine - it just doesn't fix
the problem. The unit tests are still failings as per my previous messages.
ie the following is
Done. All tests pass on my FreeBSD box. Nicolas - can you test Win32, I'm
not 100% sure if the change to test.py I made will work.
Grisha
On Tue, 13 Sep 2005, Nicolas Lehuen wrote:
Yes, now I remember I had to comment this line out because it broke
something on Win32. Go ahead, uncomment
Gregory (Grisha) Trubetskoy wrote:
Done. All tests pass on my FreeBSD box. Nicolas - can you test Win32,
I'm not 100% sure if the change to test.py I made will work.
Good news. If the changes can be checked in and Nicolas can give a +1 on
the Windows test then I'll be able to generate the
Alright, cool. So I guess we're ready to roll the next tarfile now.
Grisha
On Tue, 13 Sep 2005, Nicolas Lehuen wrote:
I'm sure it is required, even after fixing the S in APR_HAS_THREADS I tried
with and without the PyEval_AcquireLock code and the latter works while the
former doesn't. I
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 ?
In this case instead of testing for WITH_THREAD in mod_python.c :
#ifdef WITH_THREAD
maybe we could test for WITH_THREAD and
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
Gregory (Grisha) Trubetskoy wrote:
Shouldn't that be PYTHON_WITH_THREAD rather than MOD_PYTHON_WITH_THREAD?
I understand it to mean that we want the thread handling code compiled
into mod_python.
Compiling and testing right now.
Jim
On Mon, 12 Sep 2005, Nicolas Lehuen wrote:
I've
Well, it depends :
#if(defined(WITH_THREAD) APR_HAS_THREADS)
#define MOD_PYTHON_WITH_THREAD_SUPPORT 1
#else
#define MOD_PYTHON_WITH_THREAD_SUPPORT 0
#endif
It's not only a matter of Python supporting threads, we must also have
a thread-enabled APR. So that's the reason for the weird
I'm not sure I understand this, perhaps someone could write a message to
the list explaining what we're doing here so there is a record. Sorry if
I'm being slow-headed here.
To me it seems that when you use thread-related calls from Python, you
wrap those in Python defines (WITH_THREAD) and
Duh, this is becoming difficult :)
I was thinking that if APR_HAS_THREADS was 0, then Apache was forcibly
ran in prefork mode, so there was no need for thread safety at all,
given the fact that mod_python would only run one interpreter thread.
So if WITH_THREAD was not defined, ORAPR_HAS_THREADS
-1 for this patch. Actually, the patch itself is fine - it just doesn't
fix the problem. The unit tests are still failings as per my previous
messages. ie the following is getting logged in test/logs/error_log:
[Mon Sep 12 19:49:33 2005] [emerg] (2)No such file or directory:
Couldn't create
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
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
14 matches
Mail list logo
