[Python-ideas] Protecting finally clauses of interruptions

Paul Colomiets paul at colomiets.name
Tue Apr 3 21:22:50 CEST 2012


Hi Yury,

On Tue, Apr 3, 2012 at 5:09 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> You shouldn't guarantee that the *whole* chain of functions/
> coroutines/etc will be safe in their finally statements, you just
> need to protect the top coroutines in the timeouts queue.
>

For yield-based coroutines the common case is the following:

yield lock.acquire()
try:
    # something
finally:
    yield lock.release()

The implementation of lock.release() is something which
goes to distributed locking manager, so should not be interrupted.
Although I can think of some ways of fixing it using tight coupling
of locks with trampoline, but having obvious way to do it without
hacks is much better.

(Although, I don't know how `yield from` changes working with
yield-based coroutines, may be it's behavior is quite different)

For greenlets situation is a bit different, as Python knows the
stack there, but you still need to traverse it (or as Andrew
mentioned, you can just propagate flag).

> - no mechanism for interrupting a running thread.

Yes. That was intentionally to have greater chance to success.
Interruption may be separate proposal.

> In almost any coroutine library you will have a thread pool,
> and sometimes you need a way to interrupt workers.

Which one? I know that twisted uses thread pool to handle:

1. DNS (which is just silly)
2. Few other protocols which doesn't have asynchronous
libraries (which should be fixed)

The whole intention of using coroutine library is to not to
have thread pool. Could you describe your use case
with more details?

> So it's not enough even for coroutines.
>

Very subjective, and doesn't match my expectations.


-- 
Paul



More information about the Python-ideas mailing list