[Python-ideas] Learning from the shell in supporting asyncio background calls

Nick Coghlan ncoghlan at gmail.com
Sun Jul 12 04:48:14 CEST 2015


On 11 July 2015 at 20:17, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I'll sleep on that, and if I still like that structure in the morning,
> I'll look at revising my coroutine posts.

I've revised both of my asyncio posts to use this three part helper
API to work with coroutines and the event loop from the interactive
prompt:

* run_in_foreground
* schedule_coroutine
* call_in_background

I think the revised TCP echo client and server post is the better of
the two descriptions, since it uses actual network IO operations as
its underlying example, rather than toy background timers:
http://www.curiousefficiency.org/posts/2015/07/asyncio-tcp-echo-server.html

As with most of the main asyncio API, "run" in this revised setup now
refers specifically to running the event loop. ("run_in_executor" is
still an anomaly, which I now believe might have been better named
"call_in_executor" to align with the call_soon, call_soon_threadsafe
and call_later callback management APIs, rather than the run_* event
loop invocation APIs)

The foreground/background split is now intended to refer primarily to
"main thread in the main process" (e.g. the interactive prompt, the
GUI thread in a desktop application, the main server process in a
network application) vs "worker threads and processes" (whether
managed by the default executor, or another executor passed in
specifically to "call_in_background"). This is much closer in spirit
to the shell meaning.

The connection that "call_in_background" has to asyncio over using
concurrent.futures directly is that, just like schedule_coroutine,
it's designed to be used in tandem with run_in_foreground (either
standalone, or in combination with asyncio.wait, or asyncio.wait_for)
to determine if the results are available yet.

Both schedule_coroutine and call_in_background are deliberately
restricted in the kinds of objects they accept - unlike ensure_future,
schedule_coroutine will complain if given an existing future, while
call_in_background will complain immediately if given something that
isn't some kind of callable.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list