[Rodrigo Dias Arruda Senra] > reading LeakFinder's code (version 0.1.1) I was puzzled by: > > """ > if not hasattr(DB, '_lf_real_open'): > # Patch DB with a way to block open operations. > DB._open_lock = allocate_lock() > def open(self, *args, **kw): > self._open_lock.acquire() > self._open_lock.release() > return apply(self._lf_real_open, args, kw) > DB._lf_real_open = DB.open > DB.open = open > > """ > > Inside the redefined::open(), the lock is acquired and > released before delegating to the original::open(). > I wonder if: > > 1) That was done intentionally as a _step_on_the_break_ measure > 2) acquire() or release() cause a desired side effect (despite 1), > inside ZODB's inner-sanctum (that eludes me) > 3) That was not the original intention, where apply() should come > between acquire() and release() > 4) none above (I'd appreciate to learn why)
I'm not familiar with this code (haven't seen it before), but I think it's clear enough: elsewhere, getControlledRefcounts() acquires this lock. That prevents the patched DB.open() from calling the real DB.open() until getControlledRefcounts() releases the lock again. But I don't see anything to stop getControlledRefcounts() from being called while any number of other threads are in the midst of the real DB.open(). _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )