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 JohannesEbke
Recipients JohannesEbke, MartinAltmayer, gvanrossum, tatellos, vstinner, yselivanov
Date 2016-06-15.08:21:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465978869.72.0.730792032977.issue26923@psf.upfronthosting.co.za>
In-reply-to
Content
On rereading my original description, it really is not clearly described why the calling Task ends up surviving. 

Attached is a patch to the 3.5.1 asyncio/tasks.py which adds some print statements in Task.cancel().

If I execute the cancellation_test.py with the patch applied, the output looks like this:

------------------------
Cancelling the task: <Task pending coro=<gather_test() running at cancellation_test.py:20> wait_for=<_GatheringFuture pending cb=[Task._wakeup()]> cb=[Task._wakeup()]>
Entered Task.cancel() for task <Task pending coro=<gather_test() running at cancellation_test.py:20> wait_for=<_GatheringFuture pending cb=[Task._wakeup()]> cb=[Task._wakeup()]>
Task is not done() and we have a _fut_waiter: Cancelling fut_waiter <_GatheringFuture pending cb=[Task._wakeup()]>
Entered Task.cancel() for task <Task finished coro=<sleep() done, defined at /home/ebkej/.virtualenvs/kialo/lib/python3.5/asyncio/tasks.py:510> result=None>
Task is done(), refusing to cancel
Great, _fut_waiter has agreed to be cancelled. We can now also return True
Cancellation returned:  True
All children finished OK, setting _GatheringFuture results!
Finished gathering.
Proof that this is running even though it was cancelled
------------------------

The Task keeps on running because Task.cancel() trusts its _fut_waiter task to handle the cancellation correctly if its cancel() method returns True. If it returns False, it handles the Cancellation itself.

In this case, that _fut_waiter continues on, and proceeds to set results etc. so that the calling tasks cannot distinguish this from a CancellationError which has been deliberately caught.

I hope this explanation is a bit clearer than the first one.
History
Date User Action Args
2016-06-15 08:21:09JohannesEbkesetrecipients: + JohannesEbke, gvanrossum, vstinner, MartinAltmayer, yselivanov, tatellos
2016-06-15 08:21:09JohannesEbkesetmessageid: <1465978869.72.0.730792032977.issue26923@psf.upfronthosting.co.za>
2016-06-15 08:21:09JohannesEbkelinkissue26923 messages
2016-06-15 08:21:08JohannesEbkecreate