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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
