Why is SETUP_FINALLY uninterruptable[sic]?

Tim Peters tim.peters at gmail.com
Thu Aug 19 06:18:02 CEST 2004


[David Pokorny]
> Whilst swimming through Python/ceval.c, I came upon the following:
>
> PyEval_EvalFrame(...) {
> ....
> <main interpreter loop>
> ....
>    if (--_Py_Ticker < 0) {
>        if (*next_instr == SETUP_FINALLY) {
>                                    /* Make the last opcode before
>                                       a try: finally: block uninterruptable. */
>               goto fast_next_opcode;
>        }
>        _Py_Ticker = _Py_CheckInterval;
>        tstate->tick_counter++;
> ....     <do "occasional" things like let other threads run, ... occurs every
> sys.getcheckinterval() bytecodes>
> }
> 
> I've been trying to find a good reason _why_ the main loop shouldn't perform
> the check at the usual time in the (highly rare) situation where SETUP_FINALLY
> occurs as the last instruction before a check.
> So far, I've managed to confuse myself even further and come up with another
> stumper: what makes SETUP_FINALLY more special than SETUP_LOOP and
> SETUP_EXCEPT?

Jeff Epler's answer was correct:  it has to do with asynchronous
exceptions.  However, it's extremely obscure, and deserves a much
better comment than it got (I won't hesitate much to rip that code
out, given that cryptic comment).  It's also unclear (as developed
later in this message thread) exactly what it does and doesn't protect
against.

See:

    http://mail.python.org/pipermail/python-dev/2003-June/036318.html

for the only explanation that appears to exist.



More information about the Python-list mailing list