On Fri, Aug 27, 2010 at 12:46 PM, Andrew Stitcher <astitc...@redhat.com> wrote: > On Fri, 2010-08-27 at 12:32 -0700, a fabbri wrote: >> ... > >> > >> > I've not tested, but I'd be very surprised. >> >> IIRC, my strace of qpidd and client showed a ton of setsigprocmask() >> syscalls. These are not cheap. I haven't retested with this new code >> yet, but I'll be happy to see those useless (in theory) syscalls >> removed. > > Interesting, I'd still be surprised if they are any kind of bottleneck > though. > >> ... >> > The one fly in the ointment is SIGPIPE which has to have some handling >> > in a lib that does sockets and there is no portable way to disable >> > SIGPIPE on a case by case basis (AFAIK). >> >> Not sure what you mean case-by-case basis. Can you use flags = >> MSG_NOSIGNAL for all your socket send() calls? > > That is exactly what I mean by case-by-case basis, the MSG_NOSIGNAL flag > is Linux specific, there is no portable way to do this (unless you know > better). >
I see. MSG_NOSIGNAL has been adopted as part of POSIX--but I assume not implemented everywhere yet (e.g. Solaris)? Windows code is a separate issue, right? How does this sound: 1. Add a way for application and qpid libs to agree on who is handling sigpipe (e.g. constructor arg or set() func). 2. If we have support for MSG_NOSIGNAL flag, use it, and we're done (trick is coming up with autotools/cmake test for this). 3. If Qpid is handling SIGPIPE (default), set SIGPIPE to be ignored at init time, to avoid terminating processes when TCP peers go away. 4. If app is handling SIGPIPE, we're done. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
