Re: ECONNRESET not returned when calling send() on a socket

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Sun, 22 Dec 2019 21:20:41 +0000
Sad Clouds <cryintothebluesky%gmail.com@localhost> 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.