Repository navigation
concurrent.futures.Future.set_running_or_notify_cancel does not notify cancel #66820
Description
| BPO | 22630 |
|---|---|
| Nosy | @brianquinlan, @pitrou |
| Files | add_cancelled method in cancel. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2014-10-14.09:05:54.451>
labels = ['library', 'docs']
title = '`concurrent.futures.Future.set_running_or_notify_cancel` does not notify cancel'
updated_at = <Date 2019-05-07.16:26:55.520>
user = 'https://bugs.python.org/bwhmather'bugs.python.org fields:
activity = <Date 2019-05-07.16:26:55.520>
actor = 'bquinlan'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation', 'Library (Lib)']
creation = <Date 2014-10-14.09:05:54.451>
creator = 'bwhmather'
dependencies = []
files = ['36908', '36909', '36910', '37017']
hgrepos = []
issue_num = 22630
keywords = ['patch']
message_count = 4.0
messages = ['229282', '230017', '303588', '341775']
nosy_count = 4.0
nosy_names = ['bquinlan', 'pitrou', 'docs@python', 'bwhmather']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue22630'
versions = ['Python 3.2', 'Python 3.3', 'Python 3.4', 'Python 3.5']
Activity
bwhmather commentedon Oct 14, 2014
The documentation for the
set_running_or_notify_cancelmethod onconcurrent.futures.Futurestates that it will notify waiting threads and trigger callbacks after theFuturehas been cancelled, however currently this is done immediately by the call tocancel.Oddly waiters (private interface used to implement
waitandas_completed) do follow the behaviour documented for callbacks (they are called inset_running_or_notify_cancel) which means that they are not equivalent to setting a callback on each future.I have attached three possible patches:
add_cancelledmethod incancel.I believe moving to the documented behaviour (1) would be a mistake as currently
set_running_or_notify_canceland theRUNNINGstate can be skipped entirely allowing Futures to be used just as a way to send results.Should mention that I have a separate patch (which I will submit separately (or here?)) that re-implements
waitandas_completedusing only publicly exposed methods. This makes it possible to extend or replaceFuturewithout having to preserve its private interface. Unfortunately this slightly breaks compatibility due to the difference between waiters and callbacks. I thought it would be best to discuss this issue first as I don't believe the current behaviour is as intended.bwhmather commentedon Oct 25, 2014
Have uploaded patch to re-implement
waitandas_completedusing callbacks. See bpo-22729. Sorry for sitting on it for so long.pitrou commentedon Oct 3, 2017
"change-docs-and-waiters.patch" looks reasonable on the principle, but I doubt it still applies.
Also, we use Github nowadays. You may still upload patches if you prefer, but pull requests have become the recommended way to submit changes :-)
brianquinlan commentedon May 7, 2019
Ben, do you still think that your patch is relevant or shall we close this bug?