Asyncio

nested.py

import asyncio

async def stuff(val):
    print("Going to sleep for", val)
    await asyncio.sleep(val)
    print("slept")
    return val * 2

def do_stuff():
    print("do stuff")
    task = asyncio.ensure_future(stuff(1))
    loop = asyncio.get_event_loop()
    loop.run_until_complete(task)
    print("Task result is", task.result())

async def main():
    print("Start main")
    do_stuff()
    print("Main complete")

output

>>> do_stuff()
do stuff
Going to sleep for 1
slept
Task result is 2

>>> loop = asyncio.get_event_loop()
>>> loop.run_until_complete(main())
Traceback
...
RuntimeError: This event loop is already running

Conceptually, I don't see a reason why this can't be done. There is an existing event loop. I want to defer to it, and get back control when the work is done. As far as I can make out, this is exactly what asyncio is meant to achieve.

I know Nick has covered all the meaty ground above, but I find this comment interesting. This implies something will block until you get a result back, but blocking a thread that also has the event loop in it means the event loop won't be able to run. I guess it could be possible if you use signals and timers from the OS, but that does mean the event loop won't be running in those blocking times. In fact I'm pretty sure twisted does something like this to get async behaviour on windows.. it does remind me of some stuff @glyph has written about in the past too: https://glyph.twistedmatrix.com/2014/02/unyielding.html

Anyway... interesting conversation :)

@dpnova But I think that WKWebView must be registered with the event loop on the main(UI) thread.

Also, even if this task delegated to another thread, using any synchronous way to get the result will still block the main thread and freeze the GUI.

The intention of the original issue(beeware/toga#68) is that I want to effectively avoid cases like this to freeze the GUI.