This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author alex.gronholm
Recipients ajoino, alex.gronholm, asvetlov, chris.jerdonek, dreamsorcerer, gvanrossum, iritkatriel, jab, njs, tinchester, yselivanov
Date 2022-02-20.21:46:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1645393595.95.0.142602267361.issue46771@roundup.psfhosted.org>
In-reply-to
Content
> It looks more complicated -- the extra parameter needs to be passed around via the task and then into the CancelledError exception.

It reduces overall complexity by making uncancellation unnecessary and restoring backwards compatibility.

> What use case do you have that cannot be solved by some variation of the "cancel count" proposal?

I'm not sure I'm keeping proper track of the variations, but it seems it still relies on task uncancellation. But worse than that, (correct me if I'm wrong) it makes the innermost context manager handle the cancellation, even if it was requested by an outer one. If you have 3 nested "cancel scopes" and the task is cancelled once, how do you know which one of those context managers should handle the cancellation?

I'm not sure my proposal is a fix-all either, in its current form. Sure, it fixes the case where a full task cancellation would go unnoticed, but if two unrelated context managers trigger cancellation at the same time, only the first one would actually receive it. Perhaps then we need to raise a CancelledError separately for each scope? I'm not sure yet.
History
Date User Action Args
2022-02-20 21:46:36alex.gronholmsetrecipients: + alex.gronholm, gvanrossum, njs, jab, asvetlov, chris.jerdonek, yselivanov, tinchester, iritkatriel, dreamsorcerer, ajoino
2022-02-20 21:46:35alex.gronholmsetmessageid: <1645393595.95.0.142602267361.issue46771@roundup.psfhosted.org>
2022-02-20 21:46:35alex.gronholmlinkissue46771 messages
2022-02-20 21:46:35alex.gronholmcreate