Sam Morris commented on MODPYTHON-202:

I've done some more testing and it seems that APR_LOCK_PROC_PTHREAD semaphores 
will cause deadlocks when creating Session.Session objects if I hammer the 
refresh button too quickly in my browser (at intervals of less than about 0.2 

The child processes are never killed by the parent server, and any further web 
requests will also hang while trying to grab the session sempahore. This 
remains the case even if I manually kill all the child processes (I guess the 
semaphore remains grabbed forever in the parent process).

I rebuilt with the APR_LOCK_FCNTL type semaphore, and I can now hammer refresh 
as fast as possible (intervals of ~0.08 seconds) without seeing any deadlocks. 
I don't know whether this is because the PROC_PTHREAD semaphores are buggy, or 
whether the FCNTL semaphores are actually faster (fast enough to avoid the 

> Allow mechanism used by global mutex locks to be specified.
> -----------------------------------------------------------
>                 Key: MODPYTHON-202
>                 URL: http://issues.apache.org/jira/browse/MODPYTHON-202
>             Project: mod_python
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 3.2.10
>            Reporter: Graham Dumpleton
> When using experimental Apache ITK MPM, described at:
>   http://home.samfundet.no/~sesse/mpm-itk/
> global mutex locks will fail if Apache used semaphores because requests 
> against different virtual hosts run as different users and user will not have 
> permission to access the semaphore to lock it. See:
>   http://www.modpython.org/pipermail/mod_python/2006-November/022536.html
> for original mailing list post about this from Sam Morris.
> A suggested fix of finding a specific mechanism that works rather than 
> default used by Apache, seems to work:
>   http://www.modpython.org/pipermail/mod_python/2006-November/022537.html
>   http://www.modpython.org/pipermail/mod_python/2006-November/022538.html
>   http://www.modpython.org/pipermail/mod_python/2006-November/022539.html
> If available MPMs with such constraints are going to appear, may make sense 
> to have an option to configure which allows one to override at compile time 
> the default mechanism used for global mutex locks so that it can be made to 
> match what may be required for a specific MPM that Apache is compiled to use.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: 
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to