Chris McDonough wrote:
FYI,
Last week, Christian Theune and I muscled the elderly ctheune-
blobsupport-branch of ZODB into shape to work again against the ZODB
trunk.
Yay! Did you also resolve the code issues I pointed out
to Christian? The original "workingness" was a bit suspect. :)
We
Hi,
this is nasty. We detected a couple of hangs with a Zope 2.7.7 final and
(using the DeadlockDebugger) we found this situation in every of the
four threads: (See attached file for complete listing of all threads)
Threads traceback dump at 2005-10-05 14:14:07
Thread 16386 (GET
/psdsite/psd/ni
On Oct 5, 2005, at 6:11 AM, Jim Fulton wrote:
Chris McDonough wrote:
FYI,
Last week, Christian Theune and I muscled the elderly ctheune-
blobsupport-branch of ZODB into shape to work again against the
ZODB trunk.
Yay! Did you also resolve the code issues I pointed out
to Christian?
[Christian Theune]
> this is nasty. We detected a couple of hangs with a Zope 2.7.7 final and
> (using the DeadlockDebugger) we found this situation in every of the four
> threads: (See attached file for complete listing of all threads)
And there are 4 threads each stuck at self._commit_lock_acqui
Hi Tim,
Am Mittwoch, den 05.10.2005, 13:26 -0400 schrieb Tim Peters:
> I wouldn't call this "a race", because nothing here appears to be
> timing-dependent. This is the code:
Right. I mixed up terminology. Sorry.
> raises an exception. The code does seem to implicitly assume that neither
> of
[Tim]
>> The code does seem to implicitly assume that neither of those _will_
>> raise an exception, and I agree the commit lock release belongs in
>> the `finally` clause instead.
>>
>> I'll change that, but doubt it will make a difference to you: if either
>> of those did raise an exception, I e
