On Thu, 11 May 2000, Marc Lehmann <pcg@xxxxxxxx> 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... :-) -Raphael
