On 10 July 2015 at 21:48, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Why is that better than something like:
data1, data2 = asyncio.run([future1, future2])
IIUC your proposal is that run_in_background adds the tasks to an implicit global variable.
It just schedules them normally using asyncio.get_event_loop().create_task() (or run_in_executor if you pass in a callable). For folks that don't want to click through to the blog post (which has a full worked example using asynchronous timers), the full implementations of the two functions (with a slight tweak to run_in_background to make the executor configurable as well) are: def run_in_background(target, *, loop=None, executor=None): if loop is None: loop = asyncio.get_event_loop() try: return asyncio.ensure_future(target, loop=loop) except TypeError: pass if callable(target): return loop.run_in_executor(executor, target) raise TypeError("background task must be future, coroutine or " "callable, not {!r}".format(type(target))) def run_in_foreground(task, *, loop=None): if loop is None: loop = asyncio.get_event_loop() return loop.run_until_complete(asyncio.ensure_future(task))
Then the first call to run_in_foreground runs both tasks returning when future1 is ready. At that point it suspends future2 if incomplete? Then the second call to run_in_foreground returns immediately if future2 is ready or otherwise runs that task until complete?
No, it's all driven by the main asyncio event loop - the suggested functions are relatively thin shims designed to let people make effective use of asyncio with just the POSIX shell foreground & background task mental model, rather than having to learn how asyncio *really* works in order to benefit from it. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia