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
> c
On 4/24/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Tim Peters wrote:
> > Does
> >
> > with cv:
> >
> > work to replace the outer (== only) acquire/try/finally/release dance?
>
> Indeed it does - although implemented in a somewhat convoluted way:
> A lock *is* a context (or is that "cont
Tim Peters wrote:
> Does
>
> with cv:
>
> work to replace the outer (== only) acquire/try/finally/release dance?
Indeed it does - although implemented in a somewhat convoluted way:
A lock *is* a context (or is that "context manager"), i.e. it implements
def __context__(self): return self
Guido van Rossum wrote:
> Actually, what Nick describes is *exactly* how one should write code
> using a condition variable:
>
> LOCK
> while nothing to do:
> UNLOCK
> wait for the condition variable (or sleep, or whatever)
> LOCK
> # here we have something to do with the l
[Guido]
> Actually, what Nick describes is *exactly* how one should write code
> using a condition variable:
>
> LOCK
> while nothing to do:
> UNLOCK
> wait for the condition variable (or sleep, or whatever)
> LOCK
> # here we have something to do with the lock held
> remo
On 4/23/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > Do we want to add a "released" context manager to the threading module for
> > 2.5?
>
> I don't think that should be added. I would consider it a dangerous
> programming style: if the lock merely doesn't "need" to be
Martin v. Löwis wrote:
> Nick Coghlan wrote:
>> Do we want to add a "released" context manager to the threading module for
>> 2.5?
>
> I don't think that should be added. I would consider it a dangerous
> programming style: if the lock merely doesn't "need" to be held (i.e.
> if it isn't necessa
Nick Coghlan wrote:
> Do we want to add a "released" context manager to the threading module for
> 2.5?
I don't think that should be added. I would consider it a dangerous
programming style: if the lock merely doesn't "need" to be held (i.e.
if it isn't necessary, but won't hurt), one should jus
Do we want to add a "released" context manager to the threading module for
2.5? It was mentioned using the name "unlocked" in PEP 343, but never spelt out:
class released(object):
def __init__(self, lock):
self.lock = lock
def __enter__(self):
self.lock.release()
