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...  :-)


Reply via email to