Requesting a stop differs from being stopped
When work is no longer needed, cancellation can avoid unnecessary resource use or unconsumed results. A successful cancellation request can mean only that the request was accepted, without establishing that execution has already ended.
Python asyncio.Task.cancel arranges delivery of CancelledError to the coroutine, which can clean up and can explicitly suppress the exception. It is not an immediate termination of a machine thread; final cancellation depends on how the task actually completes.
References: [1]
Propagating cancellation through related scopes
One operation can start several children. Go Context propagates cancellation and deadlines through derived contexts; code can observe Done and stop unwanted work, while cancellation releases associated resources.
The signal does not insert checks into arbitrary functions. The Go documentation’s generator explicitly observes Done in a select and returns. Creating a context without code that observes it does not forcibly stop all related execution.
References: [2]
Keeping cleanup and reporting consistent
Python recommends try/finally for coroutine cleanup and generally propagating cancellation after explicitly catching it. Task groups and timeout contexts rely on cancellation internally; swallowing it can remove a completion signal required by the managing scope.
Result interfaces have different cancellation contracts too. An asyncio.Future can enter a cancelled state directly, while executor-based futures impose their own restrictions on running work. Callers must use the relevant contract and, where required, await actual cleanup before reclaiming resources still in use.