3 ms·

Performance is an argument pro unwinding, because the default case (no exception, no unwinding) does not have to check for errors.

by qznc 12y ago

cliffbean 12y ago
SIGABRT (or similar) approach is similarly tempting. No checking for errors, no complicated control paths. If Unix systems let processes register (and unregister) files to be automatically deleted on abnormal exit, it'd be pretty convenient.
- dbrower 12y ago
  The generalized form of this would take arbitrary cleanup actions, not just file deletions, and would look a lot like atexit(); In fact, one could put a SIGABORT handler in that would (a) deregister itself and (b) call exit() to run atexit handlers. Of course, if the reason for the abort was memory scrambling that destroyed the registry of cleanup actions, things get messy, which is why it needs to deregister the signal handler. I'm not keen on having to hijack the signal handler, nor of the global variables needed for the atexit (or equivalent) handler registry. All things considered, I'd rather language + compiler support for unwinding with user settable cleanup handlers, a/k/a real exceptions.
- the_why_of_y 12y ago
  That is already possible in UNIX: just unlink(2) the file and it will be automatically deleted once its last file descriptor is closed. Linux 3.11 added support for the O_TMPFILE flag to open(2) so it's not even necessary to call unlink(2).
dbaupp 12y ago
It is not nearly as simple as you are hoping. The threat of unwinding forces compilers to insert landing pads (increasing code size) and forgo some optimisations because they have to be careful to preserve semantics even during unwinding, restricting things like how much code can be reordered etc.
- qznc 12y ago
  It certainly makes things more complex for the compiler. However, I don't know an example where it would prevent an optimization.
  - veddan 12y ago
    It's not just a matter of the compiler missing optimizations. Some (unsafe, low-level) algorithms have to be written differently (and less efficiently) because of the possibility of unwinding. Disallowed patterns typically look something like * Put an object in an invalid state * Perform some operation that might unwind * Fix the object again If you unwind while the object is in an invalid state, and its destructor is called during unwinding, you can end up with undefined behavior.

Performance is an argument pro unwinding, because the default case (no exception, no unwinding) does not have to check for errors.

by qznc 12y ago

Performance is an argument pro unwinding, because the default case (no exception, no unwinding) does not have to check for errors.

cliffbean 12y ago

SIGABRT (or similar) approach is similarly tempting. No checking for errors, no complicated control paths. If Unix systems let processes register (and unregister) files to be automatically deleted on abnormal exit, it'd be pretty convenient.

dbrower 12y ago
The generalized form of this would take arbitrary cleanup actions, not just file deletions, and would look a lot like atexit(); In fact, one could put a SIGABORT handler in that would (a) deregister itself and (b) call exit() to run atexit handlers. Of course, if the reason for the abort was memory scrambling that destroyed the registry of cleanup actions, things get messy, which is why it needs to deregister the signal handler. I'm not keen on having to hijack the signal handler, nor of the global variables needed for the atexit (or equivalent) handler registry. All things considered, I'd rather language + compiler support for unwinding with user settable cleanup handlers, a/k/a real exceptions.
the_why_of_y 12y ago
That is already possible in UNIX: just unlink(2) the file and it will be automatically deleted once its last file descriptor is closed. Linux 3.11 added support for the O_TMPFILE flag to open(2) so it's not even necessary to call unlink(2).

dbaupp 12y ago

It is not nearly as simple as you are hoping. The threat of unwinding forces compilers to insert landing pads (increasing code size) and forgo some optimisations because they have to be careful to preserve semantics even during unwinding, restricting things like how much code can be reordered etc.

qznc 12y ago
It certainly makes things more complex for the compiler. However, I don't know an example where it would prevent an optimization.
- veddan 12y ago
  It's not just a matter of the compiler missing optimizations. Some (unsafe, low-level) algorithms have to be written differently (and less efficiently) because of the possibility of unwinding. Disallowed patterns typically look something like * Put an object in an invalid state * Perform some operation that might unwind * Fix the object again If you unwind while the object is in an invalid state, and its destructor is called during unwinding, you can end up with undefined behavior.