[mod_python] Re: mod_python, the ITK MPM and sessions

Graham Dumpleton grahamd at dscpl.com.au
Wed Nov 8 16:20:39 EST 2006


Sam Morris wrote ..
> On Tue, 07 Nov 2006 18:46:44 -0500, Graham Dumpleton wrote:
> > Looking at:
> > 
> >   http://apr.apache.org/docs/apr/apr__global__mutex_8h-source.html
> > 
> > you might consider changing mod_python code such that instead of
> > passing APR_LOCK_DEFAULT to the call of apr_global_mutex_create() in
> > src/mod_python.c, change it some some other specific locking
> > mechanism rather than relying on APR to choose one for you.
> 
> Thanks very much for the pointers! My results:
> 
> APR_LOCK_FCNTL: works!
> APR_LOCK_FLOCK: works!
> APR_LOCK_SYSVSEM: fail (permission denied when acquiring semaphore)
> APR_LOCK_POSIXSEM: fail (not implemented on my platform)
> APR_LOCK_PROC_PTHREAD: works!
> 
> (On my platform, Debian GNU/Linux, APR_LOCK_DEFAULT causes SysV Semaphores
> to be used).
> 
> Out of these, I guess pthread semaphores are the fastest.
> 
> Would you consider adding an option to mod_python's Apache configuration
> to
> control which semaphore implementation is chosen? I can try to come up
> with a patch for this.

Good to hear it works.

At this stage the best course of action is probably to create an issue on the
mod_python bug tracker with the suggested new feature of an option to configure
which allows the locking scheme used for the global locks to be overridden at
compile time. As well as the changes to configure, obviously need to make code
changes in src/mod_python.c and elsewhere.

Note that because of where we are at with releases this would not be looked at
until some future release after 3.3. Thus, for the time being at least, just go with
the manual change.

I'll create an issue in the bug tracking system later when I get a chance and after
I have done some research on what this experimental MPM is all about.

Graham


More information about the Mod_python mailing list