[Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

[Guido van Rossum]

On Wed, Mar 27, 2019 at 3:18 PM Nathaniel Smith <njs at pobox.com> wrote:

> On Wed, Mar 27, 2019 at 1:49 PM Guido van Rossum <guido at python.org> wrote:
>
> I just had another silly idea. What if the magical decorator that can be
> used to create a sync version of an async def (somewhat like tworoutines)
> made the async version hand off control to a thread pool? Could be a tad
> slower, but the tenor of the discussion seems to be that performance is not
> that much of an issue.
>
> Unfortunately I don't think this helps much... If your async def
> doesn't use signals, then it won't interfere with the outer loop's
> signal state and a thread is unnecessary. And if it *does* use
> signals, then you can't put it in a thread, because Python threads are
> forbidden to call any of the signal-related APIs.
>

One advantage might be that you can do this without any asyncio changes or
monkey-patches, e.g. you could do this with Python 3.6 today. In fact it
might save @tworoutine (though I can't say I find its (~foo)(args) notation
very readable, nor do I agree with its choice of making the default
synchronous.

I guess not being allowed to use signals doesn't strike me as a big deal,
and IIRC asyncio's subprocess support still works from a thread.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20190327/376d5107/attachment-0001.html>