RetroSearch Browse

Tue Apr 25 07:22:07 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-April/064320.html

Guido van Rossum wrote:
> Tim is right, the UNLOCK/LOCK part is implied in the wait() call.
> However, the wait() implementation really *does* provide a use case
> for the primitive operation that Nick proposed, and it can't be
> refactored to remove the pattern Martin disapproves of (though of
> course the existing try/finally is fine). I'm not sure if the use case
> is strong enough to warrant adding it; I think it's fine not to
> support it directly.

Ah, you mean that the wait implementation *itself* should use the
unlocked() context (which calls release on enter, and acquire on
exit). That wouldn't work, as _Condition.wait doesn't use
release/enter, but _release_save/_acquire_restore. So the unlocked
context couldn't be used there if it existed.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-April/064320.html below:

[Python-Dev] Proposed addition to threading module