You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the documentation for concurrent.futures.wait, it:
Returns a named 2-tuple of sets. The first set, named done, contains the futures that completed (finished or cancelled futures) before the wait completed. The second set, named not_done, contains the futures that did not complete (pending or running futures).
In this example, however, it returns cancelled futures in not_done. Note the wait=True in the preceding executor.shutdown call, which should ensure futures are not cancelled between wait and print. task calls sleep to ensure at least one thread is pending when executor.shutdown is called, even on especially performant systems.
If we instead call wait with timeout=None, the script hangs indefinitely.
If we replace the call to executor.shutdown with futures[1].cancel() (leave timeout=0), the cancelled future is similarly included in not_done. We can add print(futures[1].cancelled()) to ensure the cancellation is successful before the call to wait.
Replacing both, however, produces the expected result.
I couldn't find an existing report; apologies if I missed it.
This appears to be a bug in concurrent.futures.ThreadPoolExecutor: when the pool is shutdown it cancels all pending work items, however it does not call set_running_or_notify_cancel on the future, so it stays in the CANCELLED state instead of being moved to the CANCELLED_AND_NOTIFIED state.
Aside from the task being incorrectly reported as "not done", this means code that is blocking waiting on the future to complete will never be awakened (e.g. if passing wait=True to shutdown, as the OP notes, or if using as_completed etc).
duaneg
added a commit
to duaneg/cpython
that referenced
this issue
May 24, 2025
When `ThreadPoolExecutor` shuts down it cancels any pending futures, however at
present it doesn't notify waiters. Thus their state stays as `CANCELLED`
instead of `CANCELLED_AND_NOTIFIED` and any waiters are not awakened.
Call `set_running_or_notify_cancel` on the cancelled futures to fix this.
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Bug description:
According to the documentation for
concurrent.futures.wait
, it:In this example, however, it returns cancelled futures in
not_done
. Note thewait=True
in the precedingexecutor.shutdown
call, which should ensure futures are not cancelled betweenwait
andprint
.task
callssleep
to ensure at least one thread is pending whenexecutor.shutdown
is called, even on especially performant systems.Considerations
wait
withtimeout=None
, the script hangs indefinitely.executor.shutdown
withfutures[1].cancel()
(leavetimeout=0
), the cancelled future is similarly included innot_done
. We can addprint(futures[1].cancelled())
to ensure the cancellation is successful before the call towait
.I couldn't find an existing report; apologies if I missed it.
CPython versions tested on:
3.11
Operating systems tested on:
Linux, macOS
Linked PRs
The text was updated successfully, but these errors were encountered: