-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 ac
http-error.log output:
[Mon Sep 12 21:38:57 2005] [notice] mod_python: Creating 8 session
mutexes based on 150 max processes and 0 max threads.
[Mon Sep 12 21:38:58 2005] [notice] Apache/2.0.53 (FreeBSD)
mod_python/3.2.0-dev-20050912 Python/2.4.1 configured -- resuming normal
operations
[Mon Sep 12
Here's a patch (this is against 3.1.2b). Untested. This replaces GIL with
with the APR lock.
--- src/mod_python.c.orig Mon Sep 12 16:42:28 2005
+++ src/mod_python.cMon Sep 12 17:32:26 2005
@@ -31,7 +31,9 @@
* (In a Python dictionary) */
static PyObject * interpreters = NULL;
+#if
Yep, this is getting a little hairy, but nothing we couldn't handle :-)
I did a little more research. Basically, this started with Graham's patch
that addressed a problem with modules being reimported (or something).
From Graham's message:
The basic problem revolves around the Python dict
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 w
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
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
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 chec
Shouldn't that be PYTHON_WITH_THREAD rather than MOD_PYTHON_WITH_THREAD?
Grisha
On Mon, 12 Sep 2005, Nicolas Lehuen wrote:
I've checked in a changeset wherein I define MOD_PYTHON_WITH_THREAD_SUPPORT
and use it everywhere WITH_THREAD was previously used. This should do the
trick ! Now if someo
I've checked in a changeset wherein I define
MOD_PYTHON_WITH_THREAD_SUPPORT and use it everywhere WITH_THREAD was
previously used. This should do the trick ! Now if someone (like Jim)
can give us his +1, that would be great.
Regards,
Nicolas2005/9/12, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]
Just wanted to add to this message that if Jim's version runs and tests
with the trick below (envvars is executed prior to apache start, but I
don't think the tests use it, so you'll probably just have to set this var
in the shell in which the tests are run), then this would be a solution
for
OK, found it. This should work on FreeBSD where Python is threaded and
Apache is not.
[snip]
And, if you built apache without thread support, you may need to add the
following lines to $PREFIX/sbin/envvars:
LD_PRELOAD=/usr/lib/libc_r.so
export LD_PRELOAD
[snip]
On Mon, 12 Sep 2005, Gr
On Wed, Sep 07, 2005 at 11:00:07PM -0400, Gregory (Grisha) Trubetskoy wrote:
> Anybody got FreeBSD? I'm getting this. This is an old and possibly
> misconfigured system, so the problem could be on my end.
>
> FreeBSD 4.9
> apache 2.0.53 (from ports)
> python 2.3.3
...
> -I/home/grisha/src/tmp/mod
2005/9/12, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>:
On Mon, 12 Sep 2005, Jim Gallacher wrote:> *** Warning: Linking the shared library mod_python.la against the> *** static library /usr/local/lib/python2.4/config/libpython2.4.a is not> portable!
I think this was always there and its pretty
On Mon, 12 Sep 2005, Jim Gallacher wrote:
*** Warning: Linking the shared library mod_python.la against the
*** static library /usr/local/lib/python2.4/config/libpython2.4.a is not
portable!
I think this was always there and its pretty harmless.
On qemu:
Syntax error on line 44 of /usr/hom
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
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 APR_HAS_THREAD
17 matches
Mail list logo