>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      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |

Reply via email to