Closed Hawk777 closed 7 months ago
No, they can be coroutines, as something in the framework or application could explicitly await
on them periodically to drive them forward. They are relatively likely to be tasks, but they do not strictly have to be, as far as I am aware.
If they’re not a task, something has to await
them for them to run. As far as I can tell, the only tasks that the ASGI server promises to create are one for the lifespan protocol and one for each request. If any of those things is awaiting another coroutine, then that coroutine is living within the lifetime of that other task, and so cannot be killed by the ASGI server itself (because the ASGI server doesn’t even know it exists, it only runs when the task in question drives it).
What else is there that could await
them?
You can, for example, use event_loop.call_later
in order to have something run at some future time without a Task.
Ah, I guess you could call_later(the_coroutine.send)
or something like that (since call_later
itself doesn’t take a coroutine but just a normal function). I guess that makes sense, though I still find the wording a little bit confusing.
In the asyncio documentation, a distinction is made:
await
ed by some other coroutine.The basic specification page contains many occurrences of the word “coroutine” and none of the word “task”. I believe all occurrences of “coroutine” are correct (some could be changed to “coroutine function”, but I think the meaning is clear so the extra verbosity is not necessary), except for the “extra coroutines” section. I could be wrong, but it looks to me like every occurrence of the word “coroutine” in that section should actually refer to tasks, not coroutines.
Thoughts?