ECONNRESET not returned when calling send() on a socket

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

Anyone familiar with sockets programming could give me some pointers
here please?

I have a small client/server network application. Client opens a TCP
connection to a server and starts writing data, at the same time client
is expecting this server to echo data back, so is starts reading data
at the same time on the same socket. So both client and server write
and read data to each other on their sockets. I/O multiplexing on a
socket is done with poll() syscall.

Here is the problem I see with NetBSD 8.1

1. Socket is set non-blocking.

2. Server calls poll() and blocks until it returns.

3. When poll() returns is reports revents as POLLOUT, i.e. socket is
only writeable:
   (gdb) p/x pollfd_array[0]
   $2 = {fd = 0x4, events = 0x1c7, revents = 0x4}

4. Server goes into a while(1) loop and calls send() until -1 is
returned. When -1 is returned and errno is EAGAIN or EWOULDBLOCK,
server goes back to poll() to wait for read/write events. Otherwise if
errno is something else, server prints error message and cleans up the
socket and goes to listen for new connections.

Now during Step 4, I kill the client so the client TCP sends RST to the
server. During this time server is busy writing to socket with send()
syscall and for some reason send() does not return -1 with errno set to
ECONNRESET when RST arrives for this socket. What I get instead is
SIGPIPE which terminates the server process.

On Linux the same code returns -1 and sets errno to ECONNRESET. Now I
can call signal() and ignore SIGPIPE, in which case send() would return
-1 with errno set to EPIPE. However I thought that when RST was
generated for a socket, the first write to the socket should always
return -1 with errno set to ECONNRESET. It is only the second write
that should generate SIGPIPE. If that is the case, then it looks like
there is a bug in NetBSD.

Any ideas or comments?