Tim Mooney wrote: > > In regard to: Re: EPIPE, Michael Natterer said (at 12:40am on May 11, 2000): > > >This is what currently happens (ok, it happens in the handler, but WNOHANG > >*should* be absolutely safe). > >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). > > Finding a processor/OS combo where sizeof(pointer) != sizeof(int) is pretty > easy, however. How does this change your thinking? No substantially :) I meant atomic access. A 64bit Processor will still have to access it's pointers atomically even if they are larger than an integer. > >The usage of SIGCLD is strongly discouraged by Stevens and some Solaris > >document I fould recently. But Gimp uses SIGCHLD anyway. > > SIGCLD != SIGCHLD. They're distant relations, but that's it. Is that what > you were trying to say? Since you apparently have access to Stevens' APUE, > look at section 10.7 again if you don't understand what I'm talking about. Yep, this is my source of info. The only common thing between SIGCHLD and SIGCLD is that they have something to do with children. SIGCLD is nonstandard and should therefore not be used. bye, --Mitch
