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 ;)
> 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.
> 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... ;)
> 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.
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.
> 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!).
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.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
