On Fri, 12 May 2000, Marc Lehmann wrote: > On Thu, May 11, 2000 at 09:05:58PM +0200, Michael Natterer <mitschel@xxxxxxxxxxxxxxx> wrote: > > > The libgimp code could try to set the signal handler to SIG_DFL before > > > executing the code of the plug-in. > > > > We don't need to do this, as (exec()'ed) children can't inherit handlers > > from their parent anyway. > > If you ignore signals (you said so) this is very well inherited by > children (this is how programs like nohup work). However, this is not > necessarily a problem, of course. It might just be unexpected by libgimp > in the child, for example, or by plug-ins, and most probably it's not the > intented action to ignore any signals by default (where the default action > isn't ignore) in the plug-ins. Oops, you're right. Of course only signals which are connected to a handler are reset to their default disposition on exec() at.al. So ignoring SIGPIPE in the app causes it to be ignored in children, too. To avoid the need of resetting the signal we could just connect it to a dummy handler and let exec() do it's job of resetting it. > I would really prefer leaving most of the signal handlers intact (or under > program control). It would be nice if a plug-in could choose to call > > gimp_signal_safetynet (); > > If it wanted all it's signals to be clobbered. And gimp_main could change > the signals it really requires. The problem is that now, a call to > gimp_main (which doesn't return) changes signal handlers without leaving > the caller the option of not (or the option of later re-setting them > again, since "later" might be never) Hm, we install the signal stuff before the call to gimp_loop() which in turn calls the plugin's run() function after which the plugin is closed anyway. So why can't you just do the signal setting which have to be special in the run() procedure. There is nothing really happening in between (well, except the config message arriving but that shouldn't hurt). > > > signal handlers installed by the Gimp should call the ones that were > > > installed before. But then we have to support the systems that have > > > > Do you really think this is neccessary? > > I can imagine that gimp needs control over a few signals (although I > cannot imagine which ones at the moment). The current situation, however, > is, that gimp (or glib?) changes many signals in plug-ins (like SIGPIPE) > without any visible benefit. Inherited settings are not the problem here > (no handlers). Plugins connect fatal signals to the fatal handler (stacktrace), ignore SIGPIPE to get notified of a crashing gimp by the new gimp_plugin_io_error_handler() (because SIGPIPE didn't work) and they connect SIGCHLD to a handler which is identical to the one in the main app (to clean up zombies). > > I'd rather like to wait it the current code (which is not really > > different from the old one except that it uses sigaction()) works as > > expected. > > It's indeed the behaviour of the old code that's bugging me ;) But I get > a bit nervous when the number of clobbered signals increases, rather then > decreases. Only SIGCHLD and SIGPIPE disposition has changed in plugins. But I'm of course willing to change my mind if someone shows me where the problem is. (the problem may be that I still don't understand why you think you cannot change gimp_main()'s signal settings :) bye, --Mitch
