quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Morris (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
Date Thu, 09 Nov 2006 11:17:37 GMT
    [ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448429 ] 
            
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 seconds).

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 deadlock).

> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message