Raphael Quinet wrote:
> 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.
We don't need to do this, as (exec()'ed) children can't inherit handlers
from their parent anyway.
> 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.
Do you really think this is neccessary? I'd rather like to wait it the
current code (which is not really different from the old one except
that it uses sigaction()) works as expected.
I guess Tim with his hardware zoo will be able to answer the question :)
And BTW, this gimp-developer traffic is cool. Somehow remembers me of
the old days when we used to hack new features :)