Gregory (Grisha) Trubetskoy wrote:
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.
The supposition that there is a deadlock is untested and simply based on
inspecting the code. dharana was asking about using psp outside of
apache, and when I took a look at psp.py I noticed the potential
deadlock. I'll give it a whirl and see if I can lock up my server. :)
Jim
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
