[Zope-dev] Understanding LeakFinder-0.1.1

[Shane Hathaway]

On Wednesday 12 January 2005 12:15 pm, Rodrigo Dias Arruda Senra wrote:
> 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)

It's intentional.  The quick lock and unlock normally has no effect, but while 
getControlledRefcounts is running, it holds _open_lock for several seconds, 
preventing new connections.  With the lock held, it waits for other 
connections to close, clears caches, computes the refcounts, and releases 
_open_lock.  It does all this to take refcount measurements in a relatively 
controlled environment.

Like Tim said, open() calls that start before getControlledRefcounts acquires 
_open_lock will not block.  getControlledRefcounts does not account for that, 
so its call to pools.items() is unreliable.  A possible solution is for 
getControlledRefcounts to also acquire the database's connection pool lock, 
accessible via the _a and _r attributes.  But it can't hold that lock for 
long, since other threads will need it to close connections.

I didn't know anybody still uses LeakFinder. :-)

Shane