On Sun, 22 Dec 2019 21:20:41 +0000 Sad Clouds <[email protected]> wrote:
> > On NetBSD you always get SIGPIPE (whn not turned off), right? > If I remember correctly, on NetBSD sometimes I got ECONNRESET, > sometimes I got SIGPIPE, depending on at what time the other TCP > application was killed. On Linux I think I always got ECONNRESET. This is what I get on Solaris with 4 TCP sockets, when I kill the client while it is running on Linux host. Three threads get SIGPIPE signals when calling send() and one thread gets ECONNRESET errno when calling recv(): Error XXX.c:2040: XXX_send_buf() failed, Broken pipe Error XXX.c:2112: XXX_recv_buf() failed, Connection reset by peer Error XXX.c:2040: XXX_send_buf() failed, Broken pipe Error XXX.c:2040: XXX_send_buf() failed, Broken pipe But swapping them round and running server process on Linux and client process on Solaris, I get this when killing the client: Error XXX.c:2146: Client unexpectedly closed connection Error XXX.c:2040: XXX_send_buf() failed, Connection reset by peer Error XXX.c:2040: XXX_send_buf() failed, Broken pipe Error XXX.c:2040: XXX_send_buf() failed, Connection reset by peer So on Linux I get a mixture of various conditions, EOF when calling recv(), ECONNRESET and SIGPIPE when calling send(). Not sure if NetBSD behaves the same, most of the time I get SIGPIPE, but can't remember if I've ever seen ECONNRESET for send(). I handle SIGPIPE now, but don't see the value of having both SIGPIPE and ECONNRESET for a socket. The behaviour is rather inconsistent, i.e. you call send() and sometimes you get a SIGPIPE signal and sometimes you don't. Maybe it's just a Linux issue and NetBSD always sends SIGPIPE.
