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

Reply via email to