4 ms·
Right, but you engineered your application so that it only performs operations that can be safely interrupted by SIGKILL. The application deals with some kind
by hyperpape 12y ago
Right, but you engineered your application so that it only performs operations that can be safely interrupted by SIGKILL.
The application deals with some kind of stream of data. You engineer it so that processing can be interrupted at any point, and on next startup, you're fine--your data is consistent.
Now, once you have that system, I would think that handling SIGTERM is not so hard--you finish processing what's in flight already, while not trying to handle anything new.
From your earlier work, you know that this can't corrupt data. Even if SIGKILL follows while you're trying to handle SIGTERM, you're no worse off than if you just had received SIGKILL in the first place.
The downside seems to be that you now have to show that your system will reliably terminate if it receives SIGTERM.
- dimman 12y agoExactly. >The downside seems to be that you now have to show that your system will reliably terminate if it receives SIGTERM. That's not a problem unless it's followed by a SIGKILL (like from an init system).
- rdtsc 12y agoSIGTERM if not handled (caught) terminates the program.
- rdtsc 12y ago> I would think that handling SIGTERM is not so hard--you finish processing what's in flight already, while not trying to handle anything new. What is the point of SIGTERM then. Why bother messing with that code that runs in an exiting/aborting program if SIGKILL will handle. Heck, SIGTERM if not handled will just be SIGKILL. That is the main point of this -- why write 2 sets of code? Unless you can guarantee your program will always get SIGTERM then SIGKILL. You have to make sure it works correctly with SIGKILL. If you do, then why bother putting in the lines of code to handle SIGTERM?