{"id":49621,"date":"2025-10-14T14:56:52","date_gmt":"2025-10-14T18:56:52","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49621"},"modified":"2025-10-21T15:38:45","modified_gmt":"2025-10-21T19:38:45","slug":"cultivated-task-cancellation","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/10\/14\/cultivated-task-cancellation\/","title":{"rendered":"Cultivated Task Cancellation"},"content":{"rendered":"

Max Seelemann<\/a> (on his new blog<\/a>):<\/p>\n

So how do you tell if a task supports cancellation? That’s tricky to answer per-se because cancellation is voluntary behavior<\/em> and needs to be represented<\/em> in the task’s value or error type. If you’re lucky, cancellation support (or lack thereof) is documented.<\/p>

[…]<\/p>

The designated way to check for cancellation is to use static properties like Task.isCancelled<\/code>. Using static properties may seem odd at first, but it’s clever: APIs called inside the task<\/em> can check for cancellation without knowing where they’re running or taking task handles as arguments. In fact, such APIs are probably the best way to handle cancellation, as we’ll see shortly.<\/p>

[…]<\/p>

You might be thinking, “okay, nice and all. But why go to all this effort to explain something that’s baked into the system anyway?” Well, I fear here comes an inconvenient truth. Not many things in the Standard Library and Foundation have cancellation support built in. In fact, as far as I know, it’s just three<\/strong>.<\/p><\/blockquote>\n\n

Update (2025-10-15<\/a>): Max Seelemann<\/a>:<\/p>\n

\n