Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #75904

Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager

References <ff17939d-84cc-4f86-a5b9-9056d76dc9c0@googlegroups.com> <53E4CFD9.4080209@stoneleaf.us> <ls2sh7$eip$1@ger.gmane.org> <CAPTjJmpvfrEPc3tGVfhNS1W2bo9B4QR7AkK99yxMyOZND4woNQ@mail.gmail.com> <ls359h$tqv$1@ger.gmane.org>
From Chris Kaynor <ckaynor@zindagigames.com>
Date 2014-08-08 12:07 -0700
Subject Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager
Newsgroups comp.lang.python
Message-ID <mailman.12760.1407525364.18130.python-list@python.org> (permalink)

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Fri, Aug 8, 2014 at 11:35 AM, Neil D. Cerutti <neilc@norwich.edu> wrote:

> On 8/8/2014 12:16 PM, Chris Angelico wrote:
>
>> On Sat, Aug 9, 2014 at 2:05 AM, Neil D. Cerutti <neilc@norwich.edu>
>> wrote:
>>
>>> Perhaps defer release, a la a common Go pattern:
>>>
>>> with contextlib.ExitStack() as stack:
>>>      acquired = lock.acquire(blocking=False)
>>>      if acquired:
>>>          stack.callback(lock.release)
>>>          do_stuff
>>>
>>
>> There's a race condition in that - an unexpected exception could
>> happen between those two. Are you able to set the callback to be a
>> "release if acquired" atomic operation?
>>
>
> Doesn't any natural looking use of blocking=False suffer from the same
> race condition? What's the correct way to use it?
>
> Here's another attempt at context managing:
>
> @contextlib.contextmanager
> def release_if_acquired(lock, blocking=True, timeout=-1):
>     acquired = lock.acquire(blocking, timeout)
>     if acquired:
>         yield acquired
>         lock.release()
>     else:
>         yield acquired
>

What I'd probably do is:
@contextlib.contextmanager
def release_if_acquired(lock, blocking=True, timeout=-1):
    acquired = lock.acquire(blocking, timeout)
    try:
        yield acquired
    finally:
        if acquired:
            lock.release()

However, there is still the chance that a interrupt signal (ctrl+c) could
prevent the lock from being released, but I think the only 100% solution
would be to write the code in C where it cannot be interrupted within
Python. The OS could still interrupt or kill the thread, but in that case,
I don't think there is anything you can do...


> with release_if_acquired(lock, blocking=False) as acquired:
>     if acquired:
>
>         do_stuff
>
>

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Specifying `blocking` and `timeout` when acquiring lock as a context manager cool-RR <ram.rachum@gmail.com> - 2014-08-08 04:51 -0700
  Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager Ethan Furman <ethan@stoneleaf.us> - 2014-08-08 06:25 -0700
  Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-08 12:05 -0400
  Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager Chris Angelico <rosuav@gmail.com> - 2014-08-09 02:16 +1000
  Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-08 14:35 -0400
  Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-08 14:57 -0400
  Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager Chris Kaynor <ckaynor@zindagigames.com> - 2014-08-08 12:07 -0700
  Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-08 13:21 -0600
  Re: Specifying `blocking` and `timeout` when acquiring lock as a context manager Chris Angelico <rosuav@gmail.com> - 2014-08-09 08:57 +1000

csiph-web