Hacker News Reader

Comment by KerrAvon | Hacker News Reader

Yes. If you have an atexit or global destructor on a program expected to run on anything Unixlike or Windows >= NT, you’re just making things slower for the user. Unless you’re on AmigaOS, let the kernel do its job; it can release your resources much faster than you can.

View on HN

> If you have an atexit or global destructor on a program expected to run on anything Unixlike or Windows >= NT, you’re just making things slower for the user. Unless you’re on AmigaOS, let the kernel do its job; it can release your resources much faster than you can.

This is a pretty myopic view of things? There are lots of other things you might wish to do when the program terminates besides releasing resources...

Like what?

Like https://stackoverflow.com/a/9334778

Or signaling external systems, or removing lockfiles, …

Anything the kernel does not do on program exit, which is most things.

At a previous job I was using destructors to ensure motors and other actuators in a telescope would shut down properly, and in the right order. This was very important, because incorrect shutdown could cause damage to equipment and potentially people.

This was actually my main reason for using C++ to program the control software: the fact that constructors and destructors run deterministically, especially when something bad happens and an exception is thrown. And while the language doesn't specify in which order they run for global variables in different compilation units, you still know how they are ordered with respect to `main()`, and if you pay attention to how the linker works, you can actually know how they will all be ordered.

Ok but couldn’t you have done that prior to calling exit?

What problem would that have solved?

Also... can't you make that argument for anything? "Avoid unique_ptr -- can't you just free the memory before exiting?"

If your program crashes or hangs it also doesn't run static destructors. And if this is safety critical you need the cleanup guarantee anyway, for example via a supervisor or watchdog process.

Can't such a destructor be in the supervisor?

  Guard g;
  // ...call subprocess...
  // Guard::~Guard will run at exit

Of course. It is run from a supervisor, which will power off all actuators if the control software crashes. This is less ideal than a more clean shutdown though. And there is a hardware watchdog which will reboot the computer it is running on if the whole thing crashes. And hardware endswitches will physically cut power if the actuators run into a position they shouldn't be.

Can't the watchdog also perform the clean shutdown? I strongly subscribe to the Crash-only Software design principle, but it is useful to get feedback from actual experience in the field.

edit: to clarify, I'm not dogmatic, I have nothing against implmenting clean shutdown procedures for example to avoid alerts and allow quick restarts that don't need to roll-forward replay logs.

I just think that clean shutdown should be best-effort and never required for consistency/durability/safety.

We are probably in agreement.

It might be able to, but it doesn't know the state of the system. It could try to determine that somehow, but that would complicate the watchdog a lot, and that is code that is almost never exercised, so the chance that there would be bugs in that code is much higher. If shutdowns were more frequent, a crash-only design might indeed have made more sense.

For command line tools that use curses or mess with the terminal in other ways, you can leave things in a pretty ugly state if you don't clean up properly.

But sometimes not fast enough. IIRC, you can wait for a HPROCESS in Win32 with the WaitForSingleObject call but that is signaled when the application code finishes _not_ when the OS has finished it's clean up. So if the process you were waiting on was an application that would write, say, "a.txt" and you wanted to wait until that process was done so that you can read "a.txt", it is possible that you fail to open that file because the OS had not released the file resource.

Of course, I wouldn't put that clean up in an atexit.

Reply on news.ycombinator.com