bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Execution continuing after SIGINT received


From: Kevin Brodsky
Subject: Re: Execution continuing after SIGINT received
Date: Sat, 5 Aug 2017 22:45:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]