Mail Archives: djgpp/1998/01/16/06:15:40
On 14 Jan 1998, Paul Derbyshire wrote:
> In a SIGINT (or SIGQUIT, in 2.02) handler, is there a way to choose to not
> exit or to exit? What is it? (RHIDE seems to have this, for SIGINT.)
Signals such as SIGINT and SIGQUIT which are faked by DJGPP (i.e., they
are not generated by CPU exceptions such as Page Fault or GPF which map
to SIGSEGV, or numeric exceptions which map to SIGFPE) can have their
handlers do anything, including return or exit.
If a handler for SIGSEGV and its ilk returns, the program will be aborted
anyway by the DJGPP exception-handling machinery (it will say something
like ``cannot continue from exception'').
> Also, if in a SIGINT (or a SIGQUIT), another SIGINT (or SIGQUIT) is
> generated, what happens:
Your handler will be called again, on top of the first invocation, since
DJGPP does not automatically blocks further SIGINTs when SIGINT is
delivered to the program (some Unices do block it). The consequences of
this recursive invocation depend on what your handler does. If the
handler doesn't do any DOS I/O, it is safe. But if you do call DOS, you
should block further SIGINTs (or SIGQUITs, as the case may be) by calling
`sigprocmask' library function or by temporarily reverting the signal
handler to SIG_IGN. This is because DOS is somewhat involved in the
complex process that happens when Ctrl-C or Ctrl-BREAK are pressed, and
I've seen such programs crash when they don't block further signals if I
press Ctrl-BREAK twice in fast succession.
For maximum portability, a signal handler should always block its signal
upon entry, and if it plans to return, reinstall itself (by calling
`signal') and unblock itself right before it returns. The reinstall part
is because on some systems (not in DJGPP), when a signal happens, its
handler is changed to SIG_IGN before calling your handler, so without
reinstalling it, you won't see further signals after you return.
- Raw text -