On Wed, Mar 27, 2019 at 3:18 PM Nathaniel Smith <
njs@pobox.com> wrote:
On Wed, Mar 27, 2019 at 1:49 PM Guido van Rossum <guido@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.
--