You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Jim Gallacher (JIRA)" <ji...@apache.org> on 2005/08/09 04:11:35 UTC
[jira] Updated: (MODPYTHON-69) Potential deadlock in psp cache
[ http://issues.apache.org/jira/browse/MODPYTHON-69?page=all ]
Jim Gallacher updated MODPYTHON-69:
-----------------------------------
Description:
This issue was discussed on the python-dev mailing list but not followed up on. Fixing that now.
In psp.py
def dbm_cache_store(srv, dbmfile, filename, mtime, val):
dbm_type = dbm_cache_type(dbmfile)
### potential deadlock here! ###
_apache._global_lock(srv, "pspcache")
try:
dbm = dbm_type.open(dbmfile, 'c')
dbm[filename] = "%d %s" % (mtime, code2str(val))
finally:
try: dbm.close()
except: pass
_apache._global_unlock(srv, "pspcache")
"pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31 chance for a hash collision if a session is used in the same request, which would result in a deadlock. (This has been confirmed by testing.)
Most obvious solution is to use the global lock 0, which will serialize all accesses to either pspcache.dbm. Global lock 0 is also used by DbmSession, but since the lock is not held for the duration of the request there should not be any additional deadlock issues.
The fix is to replace the _apache._global_lock(srv, "pspcache") with
_apache._global_lock(srv, None, 0)
The corresponding lock handling in dbm_cache_get() will also need the same fix.
I will commit the this fix shortly.
was:
This issue was discussed on the python-dev mailing list but not followed up on. Fixing that now.
In psp.py
def dbm_cache_store(srv, dbmfile, filename, mtime, val):
dbm_type = dbm_cache_type(dbmfile)
### potential deadlock here! ###
_apache._global_lock(srv, "pspcache")
try:
dbm = dbm_type.open(dbmfile, 'c')
dbm[filename] = "%d %s" % (mtime, code2str(val))
finally:
try: dbm.close()
except: pass
_apache._global_unlock(srv, "pspcache")
"pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31 chance for a hash collision if a session is used in the same request, which would result in a deadlock. (This has been confirmed by testing.)
Most obvious solution is to use the global lock 0, which will serialize all accesses to either pspcache.dbm. Global lock 0 is also used by DbmSession, but since the lock is not held for the duration of the request there should not be any additional deadlock issues.
The fix is to replace the _apache._global_lock(srv, "pspcache") with
_apache._global_lock(srv, None, 0)
I will commit the this fix shortly.
> Potential deadlock in psp cache
> -------------------------------
>
> Key: MODPYTHON-69
> URL: http://issues.apache.org/jira/browse/MODPYTHON-69
> Project: mod_python
> Type: Bug
> Components: publisher
> Versions: 3.2.0
> Environment: All
> Reporter: Jim Gallacher
>
> This issue was discussed on the python-dev mailing list but not followed up on. Fixing that now.
> In psp.py
> def dbm_cache_store(srv, dbmfile, filename, mtime, val):
> dbm_type = dbm_cache_type(dbmfile)
> ### potential deadlock here! ###
> _apache._global_lock(srv, "pspcache")
> try:
> dbm = dbm_type.open(dbmfile, 'c')
> dbm[filename] = "%d %s" % (mtime, code2str(val))
> finally:
> try: dbm.close()
> except: pass
> _apache._global_unlock(srv, "pspcache")
> "pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31 chance for a hash collision if a session is used in the same request, which would result in a deadlock. (This has been confirmed by testing.)
> Most obvious solution is to use the global lock 0, which will serialize all accesses to either pspcache.dbm. Global lock 0 is also used by DbmSession, but since the lock is not held for the duration of the request there should not be any additional deadlock issues.
> The fix is to replace the _apache._global_lock(srv, "pspcache") with
> _apache._global_lock(srv, None, 0)
> The corresponding lock handling in dbm_cache_get() will also need the same fix.
> I will commit the this fix shortly.
--
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
Re: [jira] Updated: (MODPYTHON-69) Potential deadlock in psp cache
Posted by Jim Gallacher <jg...@sympatico.ca>.
I've committed the fix. For some reason JIRA is picking up the
subversion commits but not forwarding the message to the mailing list.
This issue can be closed.
Jim
Jim Gallacher (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/MODPYTHON-69?page=all ]
>
> Jim Gallacher updated MODPYTHON-69:
> -----------------------------------
>
> Description:
> This issue was discussed on the python-dev mailing list but not followed up on. Fixing that now.
>
> In psp.py
>
> def dbm_cache_store(srv, dbmfile, filename, mtime, val):
>
> dbm_type = dbm_cache_type(dbmfile)
> ### potential deadlock here! ###
> _apache._global_lock(srv, "pspcache")
> try:
> dbm = dbm_type.open(dbmfile, 'c')
> dbm[filename] = "%d %s" % (mtime, code2str(val))
> finally:
> try: dbm.close()
> except: pass
> _apache._global_unlock(srv, "pspcache")
>
> "pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31 chance for a hash collision if a session is used in the same request, which would result in a deadlock. (This has been confirmed by testing.)
>
> Most obvious solution is to use the global lock 0, which will serialize all accesses to either pspcache.dbm. Global lock 0 is also used by DbmSession, but since the lock is not held for the duration of the request there should not be any additional deadlock issues.
>
> The fix is to replace the _apache._global_lock(srv, "pspcache") with
> _apache._global_lock(srv, None, 0)
>
> The corresponding lock handling in dbm_cache_get() will also need the same fix.
>
> I will commit the this fix shortly.
>
>
>
> was:
> This issue was discussed on the python-dev mailing list but not followed up on. Fixing that now.
>
> In psp.py
>
> def dbm_cache_store(srv, dbmfile, filename, mtime, val):
>
> dbm_type = dbm_cache_type(dbmfile)
> ### potential deadlock here! ###
> _apache._global_lock(srv, "pspcache")
> try:
> dbm = dbm_type.open(dbmfile, 'c')
> dbm[filename] = "%d %s" % (mtime, code2str(val))
> finally:
> try: dbm.close()
> except: pass
> _apache._global_unlock(srv, "pspcache")
>
> "pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31 chance for a hash collision if a session is used in the same request, which would result in a deadlock. (This has been confirmed by testing.)
>
> Most obvious solution is to use the global lock 0, which will serialize all accesses to either pspcache.dbm. Global lock 0 is also used by DbmSession, but since the lock is not held for the duration of the request there should not be any additional deadlock issues.
>
> The fix is to replace the _apache._global_lock(srv, "pspcache") with
> _apache._global_lock(srv, None, 0)
>
> I will commit the this fix shortly.
>
>
>
>
>
>>Potential deadlock in psp cache
>>-------------------------------
>>
>> Key: MODPYTHON-69
>> URL: http://issues.apache.org/jira/browse/MODPYTHON-69
>> Project: mod_python
>> Type: Bug
>> Components: publisher
>> Versions: 3.2.0
>> Environment: All
>> Reporter: Jim Gallacher
>
>
>>This issue was discussed on the python-dev mailing list but not followed up on. Fixing that now.
>>In psp.py
>>def dbm_cache_store(srv, dbmfile, filename, mtime, val):
>> dbm_type = dbm_cache_type(dbmfile)
>> ### potential deadlock here! ###
>> _apache._global_lock(srv, "pspcache")
>> try:
>> dbm = dbm_type.open(dbmfile, 'c')
>> dbm[filename] = "%d %s" % (mtime, code2str(val))
>> finally:
>> try: dbm.close()
>> except: pass
>> _apache._global_unlock(srv, "pspcache")
>>"pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31 chance for a hash collision if a session is used in the same request, which would result in a deadlock. (This has been confirmed by testing.)
>>Most obvious solution is to use the global lock 0, which will serialize all accesses to either pspcache.dbm. Global lock 0 is also used by DbmSession, but since the lock is not held for the duration of the request there should not be any additional deadlock issues.
>>The fix is to replace the _apache._global_lock(srv, "pspcache") with
>>_apache._global_lock(srv, None, 0)
>>The corresponding lock handling in dbm_cache_get() will also need the same fix.
>>I will commit the this fix shortly.
>
>