Is this reproducable? With a 1 in 31 chance it should be pretty easy to
reproduce... Just want to make sure that there isn't some undrelying
reason why this was done this way.
Grisha
On Thu, 23 Jun 2005, Jim Gallacher wrote:
I think I just spotted a potential deadlock in psp.py.
def dbm_cache_store(srv, dbmfile, filename, mtime, val):
dbm_type = dbm_cache_type(dbmfile)
_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.
I'm sure there are other possible deadlock scenarios where some combination
of sessions and pspcache could end up trying to hold the same mutex.
Most obvious solution is to use the global lock 0, which will serialize all
accesses to either pspcache.dbm (and the dbmsession dbm in the case where
DbmSession is being used). This will result in an obvious performance hit
when psp are used in conjunction with DbmSession, but that's better than a
deadlock.
_apache._global_lock(srv, None, 0)
The alternative would be to reserve a mutex for pspcache.
If you agree that this is a possible deadlock let me know and I'll make the
simple fix. We could also take another look at the bsddb transaction handling
discussed last week in my Session benchmark post, and avoid using the mutex
altogether.
Regards,
Jim
