On Wed, Mar 27, 2019 at 3:18 PM Nathaniel Smith <n...@pobox.com> wrote:
> On Wed, Mar 27, 2019 at 1:49 PM Guido van Rossum <gu...@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)
_______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
