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
