On Wed, Dec 23, 2015 at 7:58 PM, Darren Smith <[email protected]> wrote:
> Hi,
>
> I'm trying to use libuv for building a C++ communications library; this
> library will then be used by application code. I chiefly care about TCP
> clients, and I am targeting Linux platform.
>
> During initial tests with libuv, my library (using libuv) often core dumped
> with "Broken pipe" error.  This was due to write attempts on a TCP
> connection which had just be closed at the client side (the client was just
> the telnet program).
>
> Advice in the libapi documentation is to ignore the pipe signal, ie, insert
> `signal(SIGPIPE, SIG_IGN)`.   Now this does work, however, this a bit
> onerous on the end user code; its very possible that the application code
> cannot chose to ignore this signal, and so now failed writes at the libuv
> layer can leak into other parts of the application code.
>
> Previously, when I have written my own TCP code, I would get around this by
> using the send() system call, and set the MSG_NOSIGNAL flag prior to the
> call to send().  Is there a way to use this in libuv?  I don't think is
> supports send() right now, but is that something that might come in the
> future?
>
> Thanks.

Libuv pushes the responsibility of blocking SIGPIPE to the user of the
library because:

1. It doesn't want to mess with signal dispositions implicitly, and

2. Using sendmsg(MSG_NOSIGNAL) is a lot slower than just write() or writev().

I think we would be open to a pull request that adds a flag to e.g.
uv_tcp_init_ex() that tells libuv to prefer sendmsg(MSG_NOSIGNAL).  It
kind of works out of the box already on the BSDs because libuv calls
setsockopt(SO_NOSIGPIPE).

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to