4 ms·
No you don't abort, aborting or trapping is of last effort. A shared library aborting will kill whatever it's linked to which allows zero chance of recovering.
by nwmcsween 10y ago
No you don't abort, aborting or trapping is of last effort. A shared library aborting will kill whatever it's linked to which allows zero chance of recovering. There are two sane ways to go about handling 'impossible states': The API is designed in a way that it returns error info somehow, a type system that tracks side effects in order to allow rolling back.
- astrange 10y agoYou can't roll back real side effects like network I/O; that's what it means to be a side effect. Plus crashing (on some OSes) dumps a lot of useful process state and the current stack, but if a function just returns some error code 50 there's not even a way to find which bits of its internals returned it. If you separate things by process, you can have your crash-only recovery and keep the rest of the system going.
- dleslie 10y agoThis is why "interrupted" and "incomplete" are often valid error states.
- nwmcsween 10y agoYou can roll back most real side effects like network I/O, console output it just depends on details such as protocol and framebuffer type. You also handle errors at the point of issue, not exceptions. The issue with separating by process is you have to flush the TLB on context switches.
- deleted 10y ago[deleted]