cc:ing the list, as I think this may be interesting for others. On 8/27/10 7:18 AM, "Andrew Stitcher" <[email protected]> wrote:
> On Thu, 2010-08-26 at 16:13 -0700, aafabbri wrote: >> Hi Andrew, >> >> Just curious if you observed any performance gains from your commit (below). >> Chances are you haven't tested it but I wanted to ask. > > 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. > > This change was much more for correctness than anything else. It's > really hard in a library thread to mask all signals in some parts of > your processing and then reenable to some previous state without messing > up the signal handling of some applications that are using some signals > for their own purposes. It is much better to not do any signal handling > at all on the libraries own threads if the library does not rely on > signals at all (this one doesn't). Makes sense. > > 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? > > A > >> >> Cheers, >> Aaron >> >> r957109 | astitcher | 2010-06-22 21:52:49 -0700 (Tue, 22 Jun 2010) | 3 lines >> >> QPID-2388: Do not unmask signals whilst waiting for IO to happen >> - The client and common libraries do not use signals at all so >> there is no real reason to allow signal handling on IO threads. >> > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
