This was one of my favorite talks from RustConf this year! The distinction between cancel safety and cancel correctness is really helpful.
Glad to see it converted to a blog post. Talks are great, but blogs are much easier to share and reference.
This was one of my favorite talks from RustConf this year! The distinction between cancel safety and cancel correctness is really helpful.
Glad to see it converted to a blog post. Talks are great, but blogs are much easier to share and reference.
"Cancel correctness" makes a lot of sense, because it puts the cancellation in some context.
I don't like the "cancel safety" term. Not only it's unrelated to the Rust's concept of safety, it's also unnecessarily judgemental.
Safe/unsafe implies there's a better or worse behavior, but what is desirable for cancellation to do is highly context-dependent.
Futures awaiting spawned tasks are called "cancellation safe", because they won't stop the task when dropped. But that's not an inherently safe behavior – leaving tasks running after their spawner has been cancelled could be a bug: piling up work that won't be used, and even interfering with the rest of the program by keeping locks locked or ports used. OTOH a spawn handle that stops the task when dropped would be called "cancellation unsafe", despite being a very useful construct specifically for propagating cleanup to dependent tasks.
Thanks! I definitely prefer reading blog posts over watching talks as well.