-
-
Notifications
You must be signed in to change notification settings - Fork 81
Re-entrant call waits until extra events are processed, could return sooner #44
Comments
NB. in the case:
... it may well be that a two-second task, t, begins execution. However, because it awaits, and return execution to the loop, this model would guarantee all 1 second tasks complete before all the 2 second ones. |
When a slow task and a fast task are started at the same time, and you wait on the result of the slow task first, then fast task will have already finished with its result directly available. This is normal and to be expected. If you wait on the fast task first then its result is available when the slow task is still working. So it's a matter of the order of how tasks are scheduled. If the ordering of the tasks in the example is changed, for example by using this as a master task: task = asyncio.gather(*[
async_rest_endpoint(query_param=i, sleep=1 - i/10)
for i in range(10)]) then the output becomes
It first waits on the deepest nested task (which now happens to be the fastest), and then bubbles up until the slowest task.
What you're forgetting here is that |
You're right. Should have been:
So, same question. It really seems like should be possible, since the whole process in mostly spent waiting on IO. That 2 second tasks were
... of course cannot return faster than the slowest task. But the nested tasks shouldn't be required to run as slowly as other scheduled nested (peer) tasks - and in fact could be independent of the runtime of other peers in an I/O waiting situation. |
Instead of pseudo code, could you use the real code. The relevant part is just a couple dozen lines and consists of run_until_complete and _run_once. |
In the example below have a nested call asking to run a single task on loop.
loop has other tasks queue or in execution.
Some of the nested tasks task two seconds, some take one.
Ideally, 1 seconds tasks would complete after 1 second.
It seems the duration of:
depends heavily on what is in the queue, not how much time it spent blocking. It would be much better if it returned immediately after executing nested_task.
The program otherwise looks fully asynchronous.
What I imagine is happening:
How it could be better:
The text was updated successfully, but these errors were encountered: