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):
        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've sent this mail to zope-dev because it was the only
address mentioned in the source code.

best regards,
Rod Senra

Rodrigo Senra
MSc Computer Engineer     [EMAIL PROTECTED]
GPr Sistemas Ltda       http://www.gpr.com.br

Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to