[Python-ideas] Protecting finally clauses of interruptions

[Paul Colomiets]

Hi Yury,

On Tue, Apr 3, 2012 at 3:02 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> On 2012-04-02, at 7:36 PM, Paul Colomiets wrote:
>
>> It's nice for python to have finally protection built-in,
>> but I don't see how it can be implemented in a generic way.
>
> How about adding some sort of 'interruption protocol'?
>
> Say Threads, generators, and Greenlets will have a special
> method called '_interrupt'.  While it will be implemented
> differently for each of them, it will work on the same
> principle:
>

On the first look, it's nice proposal. On the second one
we have the following problems:

1. For yield-based coroutines you must inspect stack
anyway, since interpreter doesn't have a stack, you
build it yourself (although, I don't know how `yield from`
changes that)

2. For greenlet based coroutines it is unclear what
the stack is. For example:

def f1():
    try:
        pass
    finally:
        g1.switch()

def f2():
    sleep(1.0)

g1 = greenlet(f1)
g2 = greenlet(f2)
g1.switch()

Is it safe to interrupt g2 while it's in `sleep`? (If you wonder
how I fix this problem with f_in_finally stack, it's easy. I
usually switch to a coroutine from trampoline, so this is
a boundary of the stack which should be checked for
f_in_finally).

3. For threads it was discussed several times and rejected.
This proposal may make thread interruptions slightly safer,
but I'm not sure it's enough to convince people.

Also at the first implementation we may oversight some
places where it's unsafe to break. Like for some objects
__init__/__exit__ is safe pair of functions not
__enter__/__exit__. So we might need `with` expression
to be uninterrtuptable, for the code like:

with open('something') as f:
    ...

It may break if interrupted inside `open()`. (Although, if
__enter__ is protected you can fix the problem with a
simple wrapper).

So I still propose add a frame flag, which doesn't break
anything, and gives us experiment with interruptions
without putting some experimental code into the core.

-- 
Paul