Why is SETUP_FINALLY uninterruptable[sic]?

[Michael Hudson]

"David Pokorny" <davebrok at soda.csua.berkeley.edu> writes:

> "Jeff Epler" <jepler at unpythonic.net> wrote in message
> news:mailman.1836.1092794238.5135.python-list at python.org...
> 
> >I suspect that this has something to do with code like
> >
> >    l = some_lock()
> >    l.acquire()
> >                    # MARK
> >    try:
> >        something with l held
> >    finally:
> >        l.release()
> >If an asynchronous exception happens betwen l.acquire() and the
> >SETUP_FINALLY opcode (at "MARK") , there's no guarantee that l.release()
> >is executed.
> >
> >This state of affairs always existed with KeyboardInterrupt and/or
> >signals, and it's hard to see how this fixes the problem if l.acquire()
> >is Python code, but I think that's what's going on.
> 
> I would belive you, but there is a trivial modification that circumvents
> this problem:
> 
> ---begin---
> mylock = some_lock()
> 
> try:
>     mylock.acquire()
>     something with mylock held
> finally:
>     mylock.release()
> ---end---

Huh?  If you typo the first mylock, or the acquire() call fails for
some reason, that doesn't do what you want.

Cheers,
mwh

-- 
  Famous remarks are very seldom quoted correctly.
                                                    -- Simeon Strunsky