Date: Thu, 01 Mar 2007 17:24:34 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Anton Yuzhaninov <citrin@citrin.ru> Cc: freebsd-net@freebsd.org Subject: Re: is setsockopt SO_NOSIGPIPE work? Message-ID: <45E70C52.2080500@FreeBSD.org> In-Reply-To: <1047693239.20070301194653@citrin.ru> References: <2110071423.20070301151729@citrin.ru> <20070301152942.GA27336@rambler-co.ru> <1047693239.20070301194653@citrin.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Anton Yuzhaninov wrote: > RE> It works, but only if you use send() instead of write(). > RE> Alternatively, you can control the behavior on a per > RE> message basis, by passing the MSG_NOSIGNAL in the "flags" > RE> argument to the send() call (without having to set a > RE> socket option). > > Thanks, with send() it works fine. > I think it should be documented in setsockopt(2). > AFAIK this is not a POSIX sockopt. I can only trace it back to MacOS X as the origin. Most applications I know of set the handler for SIGPIPE to SIG_IGN in such situations. Call graph: write() -> dofilewrite() -> soo_write() -> pru_send() Looking at the code for the generic write() path it looks like we would never squelch this kind of SIGPIPE intentionally. In soo_write() we check the SO_NOSIGPIPE option to tell if we should call psignal(). However, as soon as we return from soo_write(), the EPIPE is mapped to psignal() by the generic code in dofilewrite() which generates the SIGPIPE you are seeing. I think this may be a bug but in the absence of precise written requirements I can't be sure. :-) BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45E70C52.2080500>