qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: QPID-2388: Do not unmask signals whilst waiting for IO to happen
Date Tue, 31 Aug 2010 14:16:03 GMT
On Fri, 2010-08-27 at 14:20 -0700, a fabbri wrote:
> On Fri, Aug 27, 2010 at 12:46 PM, Andrew Stitcher <astitcher@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.

To elaborate - although there may be a user->system context switch these
calls are this thread only and only change a simple mask so I'd be
surprised if they really account for a significant performance loss.

> >
> >> ...
> >> > 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?

It was adopted so recently (2006) that afaik it is only in linux (it
does seems to be in FreeBSD 8 now). Not in Solaris/MacOS which would be
the other major Posix targets.

> 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.

I'm afraid this can't work in the no MSG_NOSIGNAL case, because the
application just can't opt to handle the signal on behalf of the

The library code needs to get an EPIPE in this disconnect case but if
the application handles the SIGPIPE there is no way it can then make the
send() call return EPIPE. Is there?


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message