On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 28 June 2017 at 21:40, Erik Bray <erik.m.b...@gmail.com> wrote: >> My colleague's contention is that given >> >> lock = threading.Lock() >> >> this is simply *wrong*: >> >> lock.acquire() >> try: >> do_something() >> finally: >> lock.release() >> >> whereas this is okay: >> >> with lock: >> do_something() > > Technically both are slightly racy with respect to async signals (e.g. > KeyboardInterrupt), but the with statement form is less exposed to the > problem (since it does more of its work in single opcodes). > > Nathaniel Smith posted a good write-up of the technical details to the > issue tracker based on his work with trio: > https://bugs.python.org/issue29988
Interesting; thanks for pointing this out. Part of me felt like this has to have come up before but my searching didn't bring this up somehow (and even then it's only a couple months old itself). I didn't think about the possible race condition before WITH_CLEANUP_START, but obviously that's a possibility as well. Anyways since this is already acknowledged as a real bug I guess any further followup can happen on the issue tracker. Thanks, Erik _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
