In case one task of gather
raises an exception, the others are still allowed to continue.
Well, that\'s not exactly what I need. I want to distinguish betwee
The problem with your implementation is that it calls sleepers.cancel()
after sleepers
has already raised. Technically the future returned by gather()
is in a completed state, so its cancellation must be no-op.
To correct the code, you just need to cancel the children yourself instead of trusting gather
's future to do it. Of course, coroutines are not themselves cancelable, so you need to convert them to tasks first (which gather
would do anyway, so you're doing no extra work). For example:
async def main():
tasks = [asyncio.ensure_future(my_sleep(secs))
for secs in [2, 5, 7]]
try:
await asyncio.gather(*tasks)
except ErrorThatShouldCancelOtherTasks:
print('Fatal error; cancelling')
for t in tasks:
t.cancel()
finally:
await sleep(5)
I am very surprised by this behavior since it seems to be contradictory to the documentation[...]
The initial stumbling block with gather
is that it doesn't really run tasks, it's just a helper to wait for them to finish. For this reason gather
doesn't bother to cancel the remaining tasks if some of them fails with an exception - it just abandons the wait and propagates the exception, leaving the remaining tasks to proceed in the background. This was reported as a bug, but wasn't fixed for backward compatibility and because the behavior is documented and unchanged from the beginning. But here we have another wart: the documentation explicitly promises being able to cancel the returned future. Your code does exactly that and that doesn't work, without it being obvious why (at least it took me a while to figure it out, and required reading the source). It turns out that the contract of Future actually prevents this from working. By the time you call cancel()
, the future returned by gather
has already completed, and cancelling a completed future is meaningless, it is just no-op. (The reason is that a completed future has a well-defined result that could have been observed by outside code. Cancelling a future would change its result, which is not allowed.)
In other words, the documentation is not wrong, because canceling would have worked if you had performed it prior to await sleepers
having completed. However, it's misleading, because it appears to allow canceling gather()
in this important use case of one of its awaitable raising, but in reality doesn't.
Problems like this that pop up when using gather
are reason why many people eagerly await (no pun intended) trio-style nurseries in asyncio.