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 :)
bye,
--Mitch
