Mail Archives: djgpp/1998/04/21/09:57:20
On Tue, 21 Apr 1998, Paul Derbyshire wrote:
> If a DJGPP app launches a subtask, which is also a DJGPP app, and this then
> catches SIGSEGV or another fatal signal, does this propagate all the way back to
> leave the stunned user staring at a C:\ prompt? Or does the parent task simply
> get a task returned with exit code 255?
The answer is "it depends". Signals which are raised by hardware
interrupt handlers installed by the DJGPP startup code or library
functions (if you call them) *are* propagated to the parent *if* the
hardware interrupt handler chains to the previous handler. Examples of
this variety include SIGINT (and SIGQUIT in v2.02), SIGTIMR, SIGPROF
and SIGALRM.
Contrary to what your message seems to convey, I think this is a Good
Thing (tm), since it means, for example, that you can profile the parent
and the child program together (if you care to make them use different
gmon.out file).
Signals which are raised because of CPU exceptions, like SIGSEGV and
SIGFPE, are generally *not* propagated (unless you scrog the system so
hard that the DPMI server itself gets an exception, or mess up the FPU
too much and don't clear it in the exit code).
In general, a program which doesn't want to die together with its
children, should install a signal handler before it spawns a child
program. Passing signals to the parent is Posix behavior, so by catching
signals around calls which run subprocesses, you gain portability.
It should be mentioned that DJGPP is the only DOS/Windows environment I
know of that supports such propagation of signals (maybe Cygwin does that
as well). But then DJGPP is the only DOS-based compiler which is
Posix-complaint, either.
Finally, note that a DJGPP parent program will get SIGINT even if its
child doesn't (because it is a non-DJGPP program, or because it installed
a handler that ignored the signal).
- Raw text -