Tim Mooney wrote: > > In regard to: Re: EPIPE, Michael Natterer said (at 8:22pm on May 8, 2000): > > >Unfortunately this is not the reason why gimp dies on just any aborting > >child. Although I 100% agree that SIGPIPE being fatal is the wrong thing > >to do. I browsed CVS and Gimp is connecting SIGPIPE to on_signal() since > >the beginning of CVS time. > > > >Mysteriously, as you mention, it worked before. I'm also pretty sure that > >the current state of signal processing behaves exactly like before Garry > >started to fix the SIGCHLD bug. > > The current state of signal processing does *not* behave exactly as before: > plug-in query works on alpha-dec-osf now. Using sigaction instead of signal > should improve things across the board, on all platforms. signal() on HP-UX > and Solaris was the SYSV signal, where the handler needed to be reset after > every signal (and there was therefore a race condition), so even though major > problems regarding signal handling were never reported on those platforms, > they were lurking. Ok, the handling of SIGCHLD has changed but SIGPIPE is handled as always in Gimp and the call to gimp_signal_private() emulates the old signal() > The SIGPIPE problem is because on_signal is currently treating it as a > fatal signal (see the case on_signal in app/main.c). The on_signal routine > should probably be modified to not treat SIGPIPE as fatal. That should fix > the problem Austin is seeing (that others will no doubt see too). Someone > should investigate the handler in 1.1.19 or earlier, and see what was being > done on SIGPIPE there. Nope, it unfortunately has another reason. I can't explain why it used to work with SIGPIPE being fatal but the diffs of app/main.c show no semantical changes at all down to CVS version 1.1. > Austin is also correct that calling printf from the handler is probably > asking for trouble. If a message must be written, some other method should > be found (write *is* ok from a signal handler, but won't using *that* be > fun...). Hm, I guess printf from a signal handler which aborts the program should be totally safe (while we should of course _not_ call the handler for SIGPIPE). My current theory (TM) is that there are weird implications between SIGPIPE and SIGCHLD (which we currently ignore) but I suspect this is total nonsense :) bye, --Mitch
