Mail Archives: djgpp/2000/01/03/13:49:27
On Sun, 2 Jan 2000, Damian Yerrick wrote:
> > I didn't see any bugs in what you describe. It's all expected
> > behavior.
>
> Or as Micro$oft Knowledge Base states it:
> "This behavior is by design." It's not a bug; it's a feature.
I protest the comparison ;-)
Seriously, though: unlike Microsoft, I submit that DJGPP features are
mostly just that: features, not misfeatures. There are a few problems
where the basic deficiency of the underlying OS is so staggering and hard
to fix that DJGPP just punts. But these cases are very rare, and, unlike
Microsoft, the sources are there to study, improve and/or hack.
> > In general, pressing ^C while the child program runs delivers the
> > signal SIGINT to its parent(s) as well, so the parent doesn't need to
> > do anything to terminate: it will be aborted automatically once the
> > child exits.
>
> So if a program catches SIGINT and maps it to Edit > Copy,
> then it will abort the parent when it's done?
If the parent is a DJGPP program, yes.
If the parent doesn't want to be aborted, it needs to install a
handler for SIGINT which overrides the default behavior. The handler
can be SIG_IGN in the simple cases, when you only want to ignore
SIGINT while the child runs, or it could be something more complex,
like popping a message about interrupted child (that's what Make does,
for example).
Of course, you should remember to restore the old SIGINT handler once
the child program exits.
Btw, this ``inheritance'' of signals is really a feature: it exists
because SIGINT and SIGQUIT are generated by a keyboard interrupt
handler which chains to the previous handler, and it was left like
this because on Unix, *all* signals are passsed up the child-parent
chain.
- Raw text -