Yanghao Hua <yanghao...@gmail.com> 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 executing. And it seems the synchronized call to "create_task()" alone, already created the task and placed it in a runnable queue. This is wrong!!! Consider in multiprocessing.Process(), do you place the new process in a runnable queue with a call to Process()? NO, you don't. You merely create a process object out of it. And it is Process().run() that actually flags the process is ready to run and let the OS kernel actually create that process. By analogy, calling synchronized "create_task()" shouldn't do more than create a coroutine task object. And "await task" should not simply blocking and waiting for completion of the task, but rather it place task in the runnable queue. Also, the current behavior not only awaits on t0 to complete, it also awaits t1 to complete! completely contradictrary when you look at the code and it is simply "await t0" and t1 was not even in the picture! The example works at all because if both t0 and t1 are created with create_task(), it already creating side-effects and are placed in the running queue. That is like a user-mode code is causing a side-effect in the OS kernel. "await task" is the equivalent of making the actual OS kernel syscall to get things REALLY started ... ---------- resolution: not a bug -> remind _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43736> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
