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



Reply via email to