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
I've tried to build 3.1.4 from the tarball on minotaur and of course
it works. Could it be possible that the recent changes in the
configure script cause the problem ?
Regards,
Nicolas
2005/9/10, Jim Gallacher [EMAIL PROTECTED]:
I thought I'd it a shot on minotaur as well.
Poking around a
Jim Gallacher wrote ..
Gregory (Grisha) Trubetskoy wrote:
I've been away this weekend - just got back, but I'm too busy to try
to
read all the multiple-interpreter related comments. I guess my question
is - can someone provide a quick summary of how far we are from 3.2.1b
test
2005/9/8, Jorey Bump [EMAIL PROTECTED]:
Jim Gallacher wrote:
Nicolas Lehuen wrote:
Well, why not keep our plan of releasing 3.2 ASAP and save this
problem for a later 3.2.x as a bug fix ?
Making subsequent bug-fix releases should be fast and easy. We cannot
afford to repeat the long
On 09/09/2005, at 10:02 AM, Jim Gallacher wrote:
As far as some future version breaking compatibility, I favour a
bigger jump in the major number: 3.2 - 4.0. This is server software
after all, and some people may prefer to maintain an older version for
a longer period, foregoing new features
I've been away this weekend - just got back, but I'm too busy to try to
read all the multiple-interpreter related comments. I guess my question is
- can someone provide a quick summary of how far we are from 3.2.1b test
tarbal?
Thanks!
Grisha
On Thu, 1 Sep 2005, Graham Dumpleton wrote:
Well, if I've understood Jim's mail, apart from the new MODPYTHON-77, we're all set.
Regards,
Nicolas2005/9/6, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]:
I've been away this weekend - just got back, but I'm too busy to try toread all the multiple-interpreter related comments. I guess my
Gregory (Grisha) Trubetskoy wrote:
I've been away this weekend - just got back, but I'm too busy to try to
read all the multiple-interpreter related comments. I guess my question
is - can someone provide a quick summary of how far we are from 3.2.1b
test tarbal?
I've also been away for the
On Tue, 6 Sep 2005, Jim Gallacher wrote:
As Graham stated on the weekend, the use of thread states can be very
tricky. I think we should proceed with the 3.2.1b without the fix. That way
we can take the time to make sure we understand the issues and fix it in 3.3.
If that seems reasonable,
Or speaking in diff (not tested):
--- setup.py.in.orig2005-09-01 11:42:09.082202944 -0400
+++ setup.py.in 2005-09-01 11:44:35.969872624 -0400
@@ -140,18 +140,24 @@
# this is a hack to prevent build_ext from trying to append
initmod_python to the export symbols
On 01/09/2005, at 6:19 AM, Jim Gallacher wrote:Hey Gang,I think we are ready for the 3.2.1b release. If there are no objections in the next 24 hours I'll create the package and make the announcement on python-dev.Sounds good.I'll always be hoping to sneak in just one more change (eg.
Hi Jim,
The fix for MODPYTHON-72
should be easy, unfortunately I'm quite busy right now, since my first
daughter was born three days ago... I'll do my best to have a look at
it, but if someone feels like doing it, I'll understand.
Regards,
Nicolas2005/8/26, Jim Gallacher [EMAIL PROTECTED]:
I
I think we should aim for the second beta release in the next couple of
days. I have a few questions and a list of outstanding issues.
Name of tarball: mod_python-3.2.1b.tgz?
Also, I assume a new branch called tags/release-3.2.1-BETA will be
created in subversion, correct?
Outstanding
Nicolas Lehuen wrote:
Hi Jim,
The fix for MODPYTHON-72
http://issues.apache.org/jira/browse/MODPYTHON-72 should be easy,
unfortunately I'm quite busy right now, since my first daughter was born
three days ago...
Congratulations Nicolas!
I'll do my best to have a look at it, but if
On Thu, 25 Aug 2005, Jim Gallacher wrote:
I think we should aim for the second beta release in the next couple of days.
I have a few questions and a list of outstanding issues.
Name of tarball: mod_python-3.2.1b.tgz?
yep, 3.2.1b
Also, I assume a new branch called tags/release-3.2.1-BETA
28 matches
Mail list logo
