Mail Archives: djgpp-workers/1998/01/11/07:26:16
Thanks for your feedback, Charles.
On Sat, 10 Jan 1998, Charles Sandmann wrote:
> > Finally, there's a possibility of making SIGQUIT in v2.02 disabled by
> > default at startup, and enabling it only when one of the functions
> > that catch SIGQUIT are first called by the program. This solution
> > seems like the best of both worlds, but implementing it is tricky and
> > might have some subtle bugs/features which I'd like to avoid unless
> > they are absolutely necessary. I'd like to hear opinions about this
> > option also.
>
> This is the correct thing to do in the DJGPP world.
Unfortunately, since I wrote that, I came to the conclusion that the
above trick will introduce subtle bugs into some programs. Imagine a
program that reverts all or most of the signals to some handler, then
restores them back around some function call, like `system'. One such
case might be when `sigprocmask' is called. If we enable SIGQUIT when
`signal' or `sigaction' are called, then when the signals are
reverted, they suddenly have SIGQUIT enabled under their feet, and if
the user presses the QUIT key, they will bomb anyway.
> While it might be hard or tricky, I can argue we've done without
> SIGQUIT this long, and we don't need it at all either.
DJ, the opinions from this poll seem to be about 50-50 (60-40, if I
include myself). I didn't get too many replies, btw.
So it seems that this feature is controversial, and I don't see an
easy solution that will introduce it without any effect on any program
out there.
There are two possible ways to introduce it without such effects:
either we disable SIGQUIT generation at startup and tell people to
call `__djgpp_set_sigquit_key' if they want it enabled; or we enable
it at startup, but define its default handler to be SIG_IGN. Which
way do you prefer me to do it?
- Raw text -