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