Marc Lehmann wrote:
> >However, a signal handler can do whatever it likes with the app's structures
> >as long as it uses atomic data access (which can be a pointer, as pointers
> >have the same size as integers, which are atomic. This is true at least on
> >all processors which have a GNU libc port and finding a processor
> >where pointers are not atomic looks very unlikely to me).
> 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 :)
> BTW: what's the reason for messing with SIGPIPE in plug-ins? Wasn't the
> original idea to not mess with signals in the release at all? I suffer
> quite a lot because libgimp resets signal handlers at places where you
> cannot override it ;)
The reason to ignore SIGPIPE was to make plugins to bahave like
the main app did before :) They should terminate themselves when Gimp
crashes. 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.
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