[Zope-dev] Understanding LeakFinder-0.1.1

[Tim Peters]

[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().