Marc Lehmann wrote: > > On Thu, May 11, 2000 at 12:47:22PM +0200, Michael Natterer <mitschel@xxxxxxxxxxxxxxx> wrote: > > > The only type that is atomic is sig_atomic_t. Everything else is not atomic > > > one at least one target where gimp runs. Limiting gimp to gnu-libc-platforms > > > looks very bad. > > > > See my other mail. I meant atomic data access which simply has to be > > the case or the os will go berserk :) > > If you are free to use the type you want, I would opt for sig_atomic_t, > which should be available on all platforms that gimp targets (of course, > this is only what I believe ;) And you're right. 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. > > 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. Gimp used to die on dying children. But that is what plugins should do (die on dying gimp) :) > > They should terminate themselves when Gimp crashes. > > Since the default action of SIGPIPE is to terminate the process, I > really think that ignoring the signal won't improve the situation. To > the contrary, changing all sorts of signals behind the applications > back (remember that there is no way to reset the signal handlers to the > values an application likes, as they are reset inside gimp_main!) creates > headaches for non-trviial plug-ins (like some of mine... ;) But mysteriously, it didn't work. Gimp was always connecting SIGPIPE to the fatal signal handler and we _never_ got the signal, though. You can of course set your own signal handlers or reset the signals to their default behaviour. > > So I inotrduced a handler for IO errors on the read channel which > > doesn't let them hang around as they used to do before. > > This has nothing to do with SIGPIPE, however. If the process didn't receive a > SIGPIPE before (the default action is to terminate the process), ignoring it > will have no effect. 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). > What could be the case, however, is, that gimp itself does not reset it's > signal handlers when it execs the plug-ins. If this is the case, then this > bug (not restoring signal handlers to their default) might cause many other > subtle problems. Nope, signals are set back to their default behaviour when doing an exec(). This is not the case for blocked signals but we don't block signals, we just ignore them. > > But I never claimed the new code to be the correct and final solution. > > So if it breaks perl in any way, we will of course have to change it > > again. > > It doesn't break perl. However, the whole "we will force our %$&§%& signal > 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 :) > I thought the last time this was discussed we agreed that, in the release, > the signal handling code that causes frustration and endless loops will be > disabled by default? Most of these signals have very sane default actions > (like SIGPIPE). > > 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. 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). bye, --Mitch
