This is what most modern OS X apps do. Sudden Termination support allows apps to advertise that they are in a state where they have no unsaved data (including things like window positions, which are persisted in user defaults). Generally, apps leave this state when they receive an event and reenter it at the end of a run-loop iteration.
But I think this highlights the key think missing from this discussion, which is the scope of cancellation. Cancelling an entire process, a thread, a specific asynchronous operation, an operation that spans a graph of processes, or even an entire cluster crashing are different operations and refer to different fault-tolerance domains. This is one of the problems with pthread cancellation: aside from all of the synchronous issues, it is cancelling something that is not, in any other context, treated as a fault-tolerance domain. Cancelling everything done by a scheduling entity within a shared-everything system is hard.
This a key difference with, say, Erlang. BEAM processes are shared-nothing entities, and so the approach of killing one BEAM process is something that you can reason about as a higher level.
https://lobste.rs/c/bty0fc
