On Thu, May 11, 2000 at 08:33:54PM +0200, Michael Natterer <mitschel@xxxxxxxxxxxxxxx> wrote:
> 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
counterproductive.
> 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
nowehere).
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
