On Thu, May 11, 2000 at 08:33:54PM +0200, Michael Natterer <[EMAIL PROTECTED]> 
> But we don't do bad things in the SIGCHLD handler anyway
> (no need for sharing data with the app) and in the fatal handler, we just
> quit the app.

"I'll put all my trust in you" ;)

> > > The reason to ignore SIGPIPE was to make plugins to bahave like
> > > the main app did before :)
> > 
> > I don't think plug-ins should behave like the main application ;) They
> > are, after all, plug-ins.
> This was a joke.

Same here ;)

> But mysteriously, it didn't work. Gimp was always connecting SIGPIPE to
> the fatal signal handler and we _never_ got the signal, though.

Then _is_ SIGPIPE being ignored or not just now? (confused...). However, I
think not connecting SIGPIPE to _anything_ at all is not a good solution.
Unless the plug-in needs to do some specific cleanup just terminating
silently seems like the best behaviour.

And if SIGPIPE isn't sent, changeing it's handler is even less useful.

> You can of course set your own signal handlers or reset the signals to
> their default behaviour.

This is very difficult, since libgimp changes the signal handlers after
claling gimp_main, and control doesn't return to the main application very
determistically :(

> No it hasn't. But as SIGPIPE didn't work (probably because of glib doing
> strange stuff in the main loop or whatever), I had to find another way
> (which seems to work quite nice so far).

Even better, so SIGPIPE is left alone (I presume).

> Nope, signals are set back to their default behaviour when doing an exec().

Hmm, AFAICS gimp simply calls fork and then execvp. Nothing signal related
at all (and the plug-in inherits the signal behaviour)

> > handlers on any plug-in" behaviour is making life very difficult (and this
> > has been the case before you started to change anything!).
> Good to hear that. I tested the perl plugins with the new code and it
> seemed to work, but it feels better to hear it from da perl man :)

Hah! you probably tested it more thoroughly than me, so watch out for the
_real_ complaints! ;)

> > I don't see why replacing the default behaviour of terminating the process
> > is worse than installing a signal handler that just.... terminates the
> > process anyway.
> And does a stacktrace.

Nobody needs a stacktrace from gimp + as many stacktraces as plug-ins are
currently running. Having a stacktrace for sigpipe in a plug-in seems

> We can remove them in the final release.  I would however prefer to
> leave them there (because the final release is unlikely to be bug-free).

I still get endless loops in about 2-10% of all crashes (As I said gimp
rarely crashes compared to some months ago). I just close my terminal
window since that seems to really kill it in most cases, but sometimes
gimp crashes and eats 100% cpu power for a long time, until I can detect
that it's still running somewhere in the background (printing messages to

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |

Reply via email to