try/finally question

[Michael Hudson]

Paul Rubin <phr-n2002b at NOSPAMnightsong.com> writes:

> So the obvious way to use it is:
> 
>    try:
>       db.begin()
>       x = db.do_action(first_thing)
>       y = db.do_action(second_thing)
>       db.commit()
>    finally:
>       db.cancel()
> 
> The trouble is db.cancel() is an ordinary method call--it's not atomic
> in the interpreter.  It can be interrupted and blast out of the
> finally block before finishing, and then control returns to some
> higher level with the database still locked.

With you so far, I think.

> In a C program I'd use sigsetmask to turn off interrupts during the
> critical section, but Python doesn't have that.

Might do in 2.3 (if I can get it to work more than 50% of the
time... signals and threaded libc's really seem to disagree quite a
lot).

> All I can think of are yet more try/finally blocks, which is ugly
> and which still might not close all the gaps.  In particular, I
> don't know whether calling a method from a finally block is
> guaranteed to execute the first Python statement in the method, if
> an interrupt comes at that exact instant.

Probably not.  The signal handler might get executed between the
LOAD_FAST "db" and the LOAD_ATTR "cancel", after all.

> What's the right way to handle this?

Dunno, sorry.

Cheers,
M.

-- 
  Screaming 14-year-old boys attempting to prove to each other that
  they are more 3133t than j00.
         -- Reason #8 for quitting slashdot today, from
            http://www.cs.washington.edu/homes/klee/misc/slashdot.html