[Python-ideas] Protecting finally clauses of interruptions

[Paul Colomiets]

Hi Yury,

On Tue, Apr 3, 2012 at 2:04 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> On 2012-04-02, at 6:33 PM, Paul Colomiets wrote:
>>> How's that going to work for tons of existing code?
>>>
>>
>> It isn't. But it doesn't break code any more than it
>> already is. Your proposal doesn't solve any problems
>> with existing code too.
>>
>> But anyway I don't propose any new ways to interrupt
>> code I only propose a way to inform trampoline when it's
>> unsafe to interrupt code.
>
> Well, if we're thinking only about interrupting coroutines
> (not threads), then it's going to work, yes.
>

Yes the threading stuff is more complex. For the main
thread there are few possible implementations, e.g. using
signals. If thread signals were ever implemented in python
they can be used too.

The real problem is inspecting a stack from another
thread. But my solution by itself gives a pretty big field
of experimentation. Like you can wrap every blocking call,
and check the stack on EINTR, and either send an
exception or wait a bit, like with coroutines (and you can
emit EINTR with pthread_kill, and implement waiting either
using another thread or using sys.settrace(), as I don't think
performance really matter here)

> My initial desire to use a special exception for the purpose,
> was because of:
>
> - it's easier to throw exception in the thread (the C-API
> function already exists, and we need to think about
> consequences of using it)
>

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.
E.g. I usually don't want to break finally unless it executes
too long, or if I hit Ctrl+C multiple times. And that is too
subjective, to be proposed as common behavior. I also
doubt how it can work with stack of yield-based coroutines,
as it knows nothing about this kind of stack.

> - PyPy disables the JIT when working with frames (if I recall
> correctly).  That's why I wanted 'f_in_finally' to be an
> implementation detail of CPython, hidden from the user code.
> Perhaps PyPy could implement the handling of our special
> exception in a more efficient way, without the side-effect
> of disabling the JIT.
>

Yes, I think PyPy can make some exception. Or maybe
until PyPy implement support of 3.3, some library may end up
with nice high level API, which both python implementation can
include.

-- 
Paul