[mod_python] mod_python release?

Graham Dumpleton grahamd at dscpl.com.au
Tue Jan 18 18:42:44 EST 2005


Nicolas Lehuen wrote ..
> Judging from 
> 
> http://www.apache.org/~jim/committers.html
> 
> we are 6 with commiters right on httpd-python. Maybe we could do
> something like a mod_python bug day soon and commit some of the
> patches that were published on this mailing list ? I suggest all 6
> commiters register themselves on the JIRA bug repository
> (http://issues.apache.org/jira/browse/MODPYTHON?report=select), so
> that we can assign bugs to each others.

Just for the record, here are my set of six bugs which I have posted about
over the last few months. I don't follow what is in CVS so have no idea
which ones anything has been done about. One is mentioned in the bug
repository, but the listed fix for it will only work with more recent versions
of Python, thus precluding people from using mod_python with Python 2.1.
My later fix would have worked with Python 2.1 as well.

The bugs as I have reported them are below. Anyone want to comment on
whether they have been addressed.

1. Both mod_python 2.7.10 and 3.1.3 will not work with the standard
version of Python which is shipped with MAC OS X. This is because the
Python library when loaded thinks it is already initialised when it isn't.
I supplied a fix for this in the prior posts.

  http://www.modpython.org/pipermail/mod_python/2004-August/015994.html
  http://www.modpython.org/pipermail/mod_python/2004-September/016507.html

2. The apache.import_module() module is not sufficiently thread lock
protected. This means that it is possible for multiple threads to load
distinct copies of a module at the same time. This one is in the bug
repository as:

  http://issues.apache.org/jira/browse/MODPYTHON-2

The fix there will only work with Python 2.2 or later. My later post
suggested alternate fix. Make sure followup is noted though as should
use RLock and not Lock.

  http://www.modpython.org/pipermail/mod_python/2004-October/016644.html
  http://www.modpython.org/pipermail/mod_python/2004-October/016645.html

3. If using a multithreaded MPM, if on startup of process there is large
number of accesses, it is possible that multiple interpreters can be
created for the same named interpreter. Fix was supplied.

  http://www.modpython.org/pipermail/mod_python/2004-October/016634.html

4. The value for config_dir is not setup correctly by mod_python on
Win32 platforms as it makes wrong assumption that Apache passes
through paths in DOS style when it actually uses POSIX style. Fix
was supplied.

  http://www.modpython.org/pipermail/mod_python/2004-November/016784.html

5. The interpreter name wasn't being set correctly when the directive
PythonInterpPerDirectory was being used. Described problem but did
not supply a fix.

  http://www.modpython.org/pipermail/mod_python/2004-November/016788.html

6. Not really a bug but an issue of sorts. That is, that once a option is
set using PythonOption, there is no way to unset it, nor is there a way
of setting an option to an empty string.

  http://www.modpython.org/pipermail/mod_python/2004-October/016562.html

I think that was all the things I found. I supply the fixes for a couple of
these along with Vampire since I think they can be reasonably serious
if you are using multithreading.

  http://www.dscpl.com.au/projects/vampire/PATCHES

The others I have workarounds in my code so as to avoid the problems.

Anyway, though I better review these in cases they have fallen through
the cracks.

--
Graham Dumpleton (grahamd at dscpl.com.au)



More information about the Mod_python mailing list