On 05/08/2017 20:35, Bob Proulx wrote: > > Really? It seems intuitive to me that at any trap handling level one > should handle what needs to be handled and then raise the signal > higher to the next level of the program. Software is all about layers > and abstraction. Sending the signal to one self to raise the signal > again feels good to me.
The thing is, "the next level of the program" really is another program, i.e. the one that invoked it, and you are communicating via the exit status, so it's certainly not as explicit as re-throwing an exception in C++, for instance. But sure, once you are aware of this mechanism, it's not difficult to understand the rationale. Actually, IMHO, what makes it look very counter-intuitive is the fact that you need to first reset the signal handler for SIGINT. Of course this is necessary to avoid invoking the handler recursively, but it feels very much like a workaround. WIFSIGNALED is true if "the child process [...] terminated due to the receipt of a signal that was not caught". That's not really what we want to know here; we want to know if the child process received a signal that caused it to terminate. Whether it handled SIGINT to clean up resources is irrelevant; what's relevant is that it eventually terminated as a consequence of SIGINT. Ideally, exit()ing from a signal handler should set a bit in the exit status expressing exactly this. I'll stop digressing, POSIX is what it is and we won't change it anyway ;-) For now, there's no other way to communicate with the shell, so that's fair enough. > POSIX even added a raise(3) call to make this easier. (Although I > still do things the old way.) > > man 3 raise That's a good point, it's arguably more self-explanatory than kill(getpid(), ...). Kevin
