Yanghao Hua added the comment:
by the way, another feedback, of course, curio works the way it
should, no matter where do you await ;-)
Now I start to understand why David Beazley has to create curio.
Python asyncio team should really really think about it carefully,
please. You don't have to
Andrew Svetlov added the comment:
1. Please consider `await` as a 'yield point': the point where the current task
may be suspended to get other tasks a chance to be executed.
It can be any `await`, not necessarily waiting for a task. Just a point where
asyncio event loop gives a chance to r
Yanghao Hua added the comment:
Poking around a bit more revealed another interesting behavior and now I
understand what went wrong with asyncio.create_task() :-)
In the example I show, you don't have to "await t1", you only have to "await
t0/t1", e.g. await on one of them, and both starts ex
Yanghao Hua added the comment:
This unfortunately contradicts to all the other concurrency semantics
I know, I have myself implemented various event-driven schedulers and
none of them would behave like this.
Consider an OS as the simplest example, you have a main thread that
starts many child
Zachary Ware added the comment:
You missed something :)
By immediately awaiting the result of `create_task`, you're synchronizing
thing. It's the same as just rearranging the lines of the first example to:
t0 = create_task(task("T0", 10))
print("starting tasks ...")
await t0
t1 = create_tas
New submission from Yanghao Hua :
This code runs perfectly fine with expected behavior: two tasks created,
executed in an interleaved manner:
from time import time
from asyncio import run, create_task, sleep
async def task(name, n):
for i in range(n):
print(f"task-{name}: ", i, t
