Hacker News Reader

Comment by qznc | Hacker News Reader

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

View on HN

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.

It certainly makes things more complex for the compiler. However, I don't know an example where it would prevent an optimization.

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.

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.

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).

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.

Reply on news.ycombinator.com