Though, I would draw a further distinction between cooperative cancelation, synchronous or asynchronous (where custom user code runs during unwinding) and uncooperative "abandonment", where user code doesn't have much control over the tearing down process. Unix and BEAM processes are examples of the latter. And, for the purposes of fault isolation, you generally want abandonment, not cancelation, because some faults don't give you a way to cooperate. (and, again, there are also gray faults, where nothing fails, but the system still doesn't hit SLOs).
So, I actually would disagree somewhat with the diagnosis of
pthread_cancel issue. I agree that, because it is shared everything, it's not a good boundary for fault isolation, when you are unsure what is the correct state, and you would rather start from a clean slate. But that issue doesn't by itself preclude the cooperative cancelation scenario, where you want to cancel the work not because of some catastrophic error elsewhere, but simply because it is no longer needed.This sort of cancelation we can get working in shared mutable systems, as evidenced by error handling mostly, if imperfectly, working. We can somewhat consistently wrap our mutexes with RAII, so they are unlocked properly.
pthread cancellation still doesn't work there, but for a different reason --- releasing resources during cancelation really wants to be a language concern, but
pthread_cleanup_push is a c runtime thing. You really don't want to code two resource release path, a normal one for break and return and try, and another one to handle pthread_cancel specifically.Modern async runtimes, like trio, work sort-of like pthread cancel, where cancelation is observed at an await point, but then it is propagating using language's normal mechanism for unwinding, re-using all the cleanup code we already know how to write.
Go, as usual, is a fun example here, where historically language-level defer desugared into runtime
cleanup_push / cleanup_pop (these days, I believe Go compiler usually optimizes runtime cleanup stack away).https://lobste.rs/c/0yxmek
