Jeff is right, the read() returns 0, not -1. Anyway, the server program
was crashed at select() as in my previous email. It is not the write()
problem as there is no write() in my server program. As I said in my
last email, I am really looking for a network system call to gracefully
respond the client termination. The SIGPIPE with SIG_IGN did not work.
Thank you.
Cheers.
Jim
Jamie Lokier wrote:
Jeff Haran wrote:
I think a read() will return 0 if the peer closes the socket, not an
error, at least this should be true on the first read() after the close,
assuming the socket RX queue was empty at the time.
However, if there's data in flight _to_ the peer _after_ the peer
closes the socket, the peer may respond with a RST packet and if
that's received locally, read() will return an error instead of 0 -
even if there's data in the socket RX queue. If that's not desired,
then design your higher-level protocol so that it doesn't do that.
will occur on write()s to the socket after its closed by the peer. The
send() function can be used instead of write() to avoid the SIGPIPE if
you pass it MSG_NOSIGNAL as one of its flags. That way you get EPIPE
back in errno and can handle the error at the point it occurs rather
than trying to deal with it in a signal handler.
You can also set the signal handler for SIGPIPE to SIG_IGN (ignore),
so that write() returns EPIPE. (Using send() + MSG_NOSIGNAL is better
because that way your program will terminate properly when debugging
messages are printed on standard output and piped to something like
less which is then quit... But it's not portable).
-- Jamie
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
