5 ms·

I was curious how Windows handled process teardown not too long ago, dug into it, and realized it just kills the process instantly. Which seems both brilliant a

I was curious how Windows handled process teardown not too long ago, dug into it, and realized it just kills the process instantly. Which seems both brilliant and awful at the same time. Any idea how other systems handle teardown?

david2ndaccount 5y ago
Your application needs to be robust in the face of the power going out, being OOM killed and other non-orderly shutdowns. Given that, there’s no point in using a different mechanism for an orderly shutdown. Just exit, don’t run destructors, they’re a waste of time.
- dataflow 5y ago
  Everything needs to be perfect, so there's no point in accommodating anything less than perfect?
- 112233 5y ago
  Is it somehow possible to tell gcc/llvm “This program will never terminate normally. Please don’t bother with static dtors” ? Or at least somehow purge all that code when linking?
  - cozzyd 5y ago
    Strip .fini ?
kccqzy 5y ago
man 3 exit The exit() function causes normal process termination and the least significant byte of status (i.e., status & 0xFF) is returned to the parent (see wait(2)). All functions registered with atexit(3) and on_exit(3) are called, in the reverse order of their registration. (It is possible for one of these functions to use atexit(3) or on_exit(3) to register an additional function to be executed during exit processing; the new registration is added to the front of the list of functions that remain to be called.) If one of these functions does not return (e.g., it calls _exit(2), or kills itself with a signal), then none of the remaining functions is called, and further exit processing (in particular, flushing of stdio(3) streams) is abandoned. If a function has been registered multiple times using atexit(3) or on_exit(3), then it is called as many times as it was registered. All open stdio(3) streams are flushed and closed. Files created by tmpfile(3) are removed. These all happen inside userspace. The kernel doesn't necessarily know it's exiting. It's _exit() that tells the kernel the process is exiting. The kernel then does some more processing like closing file descriptors. man 2 _exit _exit() terminates the calling process "immediately". Any open file descriptors belonging to the process are closed. Any children of the process are inherited by init(1) (or by the nearest "subreaper" process as defined through the use of the prctl(2) PR_SET_CHILD_SUBREAPER operation). The process's parent is sent a SIGCHLD signal. The value status & 0xFF is returned to the parent process as the process's exit status, and can be collected by the parent using one of the wait(2) family of calls.
yakubin 5y ago
Why awful?
ahartmetz 5y ago
Reminds me of an "interesting" but mostly useless idea I had... to speed up orderly process termination on Linux, monkeypatch free() (I'm thonking of messing with symbol resolution, better than adding a conditional in the hot path) to do nothing during exit. Problem is, it's already quite fast and no one cares. There are some potential problems with that but why attack them if no one needs the feature?

david2ndaccount 5y ago

Your application needs to be robust in the face of the power going out, being OOM killed and other non-orderly shutdowns. Given that, there’s no point in using a different mechanism for an orderly shutdown. Just exit, don’t run destructors, they’re a waste of time.

dataflow 5y ago
Everything needs to be perfect, so there's no point in accommodating anything less than perfect?
112233 5y ago
Is it somehow possible to tell gcc/llvm “This program will never terminate normally. Please don’t bother with static dtors” ? Or at least somehow purge all that code when linking?
- cozzyd 5y ago
  Strip .fini ?

kccqzy 5y ago

man 3 exit The exit() function causes normal process termination and the least significant byte of status (i.e., status & 0xFF) is returned to the parent (see wait(2)). All functions registered with atexit(3) and on_exit(3) are called, in the reverse order of their registration. (It is possible for one of these functions to use atexit(3) or on_exit(3) to register an additional function to be executed during exit processing; the new registration is added to the front of the list of functions that remain to be called.) If one of these functions does not return (e.g., it calls _exit(2), or kills itself with a signal), then none of the remaining functions is called, and further exit processing (in particular, flushing of stdio(3) streams) is abandoned. If a function has been registered multiple times using atexit(3) or on_exit(3), then it is called as many times as it was registered. All open stdio(3) streams are flushed and closed. Files created by tmpfile(3) are removed. These all happen inside userspace. The kernel doesn't necessarily know it's exiting. It's _exit() that tells the kernel the process is exiting. The kernel then does some more processing like closing file descriptors. man 2 _exit _exit() terminates the calling process "immediately". Any open file descriptors belonging to the process are closed. Any children of the process are inherited by init(1) (or by the nearest "subreaper" process as defined through the use of the prctl(2) PR_SET_CHILD_SUBREAPER operation). The process's parent is sent a SIGCHLD signal. The value status & 0xFF is returned to the parent process as the process's exit status, and can be collected by the parent using one of the wait(2) family of calls.

yakubin 5y ago

Why awful?

ahartmetz 5y ago

Reminds me of an "interesting" but mostly useless idea I had... to speed up orderly process termination on Linux, monkeypatch free() (I'm thonking of messing with symbol resolution, better than adding a conditional in the hot path) to do nothing during exit. Problem is, it's already quite fast and no one cares. There are some potential problems with that but why attack them if no one needs the feature?