patch for SIGPIPE in tds_write_packet

James Cameron james.cameron at compaq.com
Wed Jan 26 17:27:17 EST 2000


Geoff Winkless wrote:
> [...] whether disconnecting the client from the server at the server
> end would cause a SIGPIPE (as it does in write()) or if it merely
> causes read() to fail with an error returned.

It causes read() to return zero.  I've not heard of the possibility of
SIGPIPE.  None of my (other) code has seen that.

It is difficult to discriminate between an empty input queue with
non-blocking I/O enabled and a terminated connection.

> I suppose I could write some test code, I was just wondering if anyone
> knew the answer already.

I've studied this for a long time.
It is also covered in the sockets FAQ.
http://www.cs.ruu.nl/wais/html/na-dir/unix-faq/socket.html

Have a look also at http://quozl.us.netrek.org/xd/ for a generic TCP/IP
relay program that I wrote months ago.  It uses select() to wait for the
socket to be readable, then uses read() to read it.  If read() returns
zero after select() says the socket is ready for reading, then that
means the remote host closed the connection, either with shutdown() or
close().

Remember it is possible for the remote host to shutdown(), saying it
intends to send no more, but it may still accept more.  Or vice versa!

So SIGPIPE on write() is a different thing to read() returning zero. 
The former means the remote host will not accept more data (either due
to shutdown() or close()), and the latter means the remote host will not
send more data (again, either due to shutdown() or close()).

Fun, eh?

-- 
James Cameron                                      (cameron at stl.dec.com)

http://www.opensource.org/ http://vanilla.us.netrek.org/ http://lwn.net/



More information about the FreeTDS mailing list