On Thu, 11 May 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> What could be the case, however, is, that gimp itself does not reset it's
> signal handlers when it execs the plug-ins. If this is the case, then this
> bug (not restoring signal handlers to their default) might cause many other
> subtle problems.
The libgimp code could try to set the signal handler to SIG_DFL before
executing the code of the plug-in.
Another solution is to save and re-install the old signal handler. We
may even want to support some kind of chain of signal handers: the new
signal handlers installed by the Gimp should call the ones that were
installed before. But then we have to support the systems that have
SA_SIGINFO and those that do not have it (this is not part of POSIX).
The systems that have SA_SIGINFO are using extended prototypes for the
signal handlers, so some #ifdef's will be necessary if we want to do
that in the right way. I could contribute some code if you want,
because I already did that in some other projects.
> I thought the last time this was discussed we agreed that, in the release,
> the signal handling code that causes frustration and endless loops will be
> disabled by default? Most of these signals have very sane default actions
> (like SIGPIPE).
Hmmm... In the last discussion, I said that I would implement a
compile-time and a run-time option for choosing this, because some
people (including myself) do like the option to have a stack trace
(when it works). But I did not take the time to do it. If you kick
me enough, I will do it... :-)