[a1369209993]

You don't need unwind safety (for anything, ever); a error kennel is more commonly known as a "process"; when a panic occurs

> you always kill the whole [process] in which the panic occurred and don't share mutable state between [process]s

Processes are designed for this, including making it very hard to accidentaly share mutable state (using eg mmap(MAP_SHARED) explicitly).

[dathinab]

Sure, but having process error kernels isn't at all appropriate for many applications. E.g. you don't start a process for every http request (or actor request) your server handles (even starting a thread for everyone is considered to much overhead).

But not only is the overhead of "starting"/entering a error kernel a problem you also normally do share _immutable_ state (e.g. configs, lookup tables), as well as some _minor_ amount of mutable but well known to be panic safe state (e.g. simple performance counters and some caches). Which is now much harder to get right.

E.g. in a cache you want it potentially to be shared across error-kernels and re-use it after a kernel crashed but only if the panic didn't come from the cache. So the cache needs to be handled in it's own error-kernel which makes it important to make the intercommunication fast.

Sure you _can_ do all this with processes (by using both IPC and mmap together), but it's much harder to get right. Often this leads to either serve performance limitations or braking of the kernels surface (by using mmap in a bad way). It also tend to lead to code which is very dependent on the features of a specific operating system. Problems with managing startup/shutdown (no systemd isn't a solution ), moving resources between kernels etc.

So all in all processes make thinks more complex, less portable with very little to no benefits for many use cases. (Sandboxing of very large error-kernels like done in browsers is one point where it makes sense).