4 ms·

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 use

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.

dataflow 3y ago
> 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...
- pizlonator 3y ago
  Like what?
  - dataflow 3y ago
    Like https://stackoverflow.com/a/9334778 https://stackoverflow.com/a/9334778
    - masklinn 3y ago
      Or signaling external systems, or removing lockfiles, … Anything the kernel does not do on program exit, which is most things.
  - gsliepen 3y ago
    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.
    - pizlonator 3y ago
      Ok but couldn’t you have done that prior to calling exit?
      - dataflow 3y ago
        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?"
    - gpderetta 3y ago
      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.
      - dataflow 3y ago
        Can't such a destructor be in the supervisor? Guard g; // ...call subprocess... // Guard::~Guard will run at exit
      - gsliepen 3y ago
        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.
        gpderetta 3y ago
        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.
  - microtherion 3y ago
    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.
nmcveity 3y ago
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.

dataflow 3y ago

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

pizlonator 3y ago
Like what?
- dataflow 3y ago
  Like https://stackoverflow.com/a/9334778 https://stackoverflow.com/a/9334778
  - masklinn 3y ago
    Or signaling external systems, or removing lockfiles, … Anything the kernel does not do on program exit, which is most things.
- gsliepen 3y ago
  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.
  - pizlonator 3y ago
    Ok but couldn’t you have done that prior to calling exit?
    - dataflow 3y ago
      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?"
  - gpderetta 3y ago
    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.
    - dataflow 3y ago
      Can't such a destructor be in the supervisor? Guard g; // ...call subprocess... // Guard::~Guard will run at exit
    - gsliepen 3y ago
      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.
      - gpderetta 3y ago
        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.
- microtherion 3y ago
  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.

nmcveity 3y ago

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.