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 again. bye, --Mitch
