multi-task asyncio flow control: who gets control when a nested `await' is called?

[brianreinhold]

If one has two asyncio tasks running concurrently (via gather, group, or whatever), who gets control when an await is called in a given task? This await can be deeply nested in the task. Does the flow always go to the last await called in the next task or does it go to a higher level await in the same task?

Consider this very simple two-task example:

taskBt: asyncio.Task[None] 
taskAps: asyncio.Task[None]

async def shutdown():
    global taskBt, taskAps
    print('Shutdown is running.')
    taskAps.cancel()
    taskBt.cancel()
    await asyncio.sleep(1)
    print('done')

async def main():
    global taskBt, taskAps
    taskBt = asyncio.create_task(find_supported_device())
    taskAps = asyncio.create_task(check_aps())

    while True:
        await asyncio.sleep_ms(0)


if __name__ == "__main__":
    try:
        asyncio.run(main())
    except KeyboardInterrupt:
        print('Keyboard Interrupt Clean up')
        asyncio.run(shutdown())

This is a VS Code example running on the PICO-W. The two tasks are complicated with many nested async/await calls. One is a bluetooth le central client communicating with health devices using aioble and the other communicates with a back end using mqtt and https. At the moment the individual tasks do not create additional tasks.

Does control go to taskAps any time an await statement is called in taskBt and vice versa? I believe this is the case but I could not find any documentation on asyncio behavior that explicitly says so.

[sophiedegran]

Hi
Did you look at the Peterhinch async tuto?
github.com/peterhinch/micropython-async/blob/master/v3/docs/TUTORIAL.md
What you say is for me right
I suggest you to download the git which is full of examples and very nice explain..
Hope that help

[brianreinhold]

Actually I have. The 'concepts' part strongly suggests to me that my assumptions are correct but it is still only suggestive. I am just looking for an explicit statement. My example does not reveal anything because only one task (the bluetooth) has significant implementation. The other is just an asyncio.sleep() for a finite delay. The delay is too coarse to reveal anything. As it gets more complicated with real behavior, it will become clear. In the meantime I am going to assume that when ANY await is met control goes to the next task in the queue and begins at the last await method in that task. It does not matter where that await occurs, even if deeply nested in some library.

[sophiedegran]

Yes and sometimes the 'schedule' is very helpful to 'force' your async tasks (see SCHEDULE.md)

[bixb922]

Any runnable task can be scheduled as next task. As a good programming practice, the program logic should not rely on what task runs next. If you need a certain execution order or task priorities, that could be achieved with asyncio.Events or asyncio.Lock or by putting the code in the right order in the same task.

[brianreinhold]

@bixb922 I do not need any order. I just wanted to be sure that the other tasks would get a chance to run. I did not want nested async/awaits within a task to resolve before another task got to run. If I have six tasks, I want each task to get an (equal) chance.

[bixb922]

OK, now I understand. AFAIK asyncio scheduling is round robin. So whenever a task reaches await, the other task is scheduled, if it's not waiting,just as you describe.

[peterhinch]

That is correct. See this section in the tutorial.