Tim Mooney wrote:
> I just looked at 1.1.19, and on_signal there was doing the same thing it
> is now: SIGPIPE caused a call to gimp_terminate.  Obviously the current code
> is based on the older code.
> So why is Austin observing the problem now?  I'm not sure.  It does seem
> like it's behaving as expected based on the code.  The thing to try would
> be to use a different signal handler for SIGPIPE, that doesn't terminate
> the gimp.  Perhaps just ignore the signal and let the plug-in protocol detect
> the problem (assuming it can?)?

We should probably ignore SIGPIPE totally and let a more sophisticated
SIGCHLD handler do the work:

- record which processes have been started ("gimp_nanny()")
- on SIGCHLD check if it crashed...
- ...and somehow clean up the plugin's struct and io channels
     (and show a proper error message)

The problem with this may be that we need a periodic function doing the cleanup
(just like the shell prints it's "bla exited [SIGwhatever]" message before the
prompt) because we cannot do it from the handler.

OTOH it should be ok to call this cleanup function from two places:

1. whenever read/write from/to a plugin pipe fails.
2. in an idle function.

The "gimp_fork()" and signal handler stuff I proposed during the SIGCHLD
discussion might so the job but it would be much nicer to fix it to work like
before :)


Reply via email to