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


Reply via email to