![](https://secure.gravatar.com/avatar/047f2332cde3730f1ed661eebb0c5686.jpg?s=120&d=mm&r=g)
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. -- --Guido van Rossum (python.org/~guido)