Date: Wed, 19 Mar 2003 11:45:06 +0200 From: Peter Pentchev <roam@ringlet.net> To: Luigi Rizzo <rizzo@icir.org> Cc: net@FreeBSD.ORG, Tristan Goode <tgoode@iprimus.com.au> Subject: Re: write(2) SIGPIPE on a closed socket? Message-ID: <20030319094506.GB27330@straylight.oblivion.bg> In-Reply-To: <20030319013748.A84035@xorpc.icir.org> References: <20030319093002.GT468@straylight.oblivion.bg> <20030319013748.A84035@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2003 at 01:37:48AM -0800, Luigi Rizzo wrote: > On Wed, Mar 19, 2003 at 11:30:02AM +0200, Peter Pentchev wrote: > ... > > dnscache) getting a SIGPIPE when attempting to write to an incoming > > connection's socket. Presumably, the client closed the connection in > ... > > The question: if the client closed the socket, shouldn't a write(2) > > return -1 with errno =3D=3D EPIPE before sending a SIGPIPE? Does anyone >=20 > well, what would "before" mean ? the system sends a signal when > the error is detected, not after an arbitrary amount of time > to give the user a chance of handling the return from the syscall. Well, the documented behavior of write(2) - and the one I have seen on many cases when writing to a socket or a FIFO - is that the first time a write is attempted after the fd is no longer available for writing, write(2) returns -1 and sets errno to EPIPE. This is the way read(2) behaves, too; this is the way programs are written to accommodate - dnscache does a check for write(2) returning -1, and closes the connection if this condition is detected. IMHO, this is way more logical - the system call should first try to return an error, so the application can detect a problem *immediately*, not asynchronously via signal handlers setting flags and such. I - and many others, apparently - have come to depend on the fact that the first read(2) or write(2) operation on a closed socket will return -1, and only if I am foolish enough to attempt a second one will the system send me a signal (isn't this the whole purpose of SIGPIPE - forcibly terminate foolish applications which do not honor errors signalled by return code?). > Sounds like the correct approach is to set the handler for > SIGPIPE to sig_ign This would work, but is somewhat besides the point IMHO. > Maybe one should wonder why this is not just the default given > that you can get this signal not because your program > did something wrong, but because the other end did. See above; it is much easier for the program to understand that something is wrong if the system call will return -1, *as documented* in the write(2) manual page. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+eDwi7Ri2jRYZRVMRAp7TAJ9ClQ6nyNeb1pKHqcJ+hZueV6ZQIACeLyq5 Wjjt8S7KXBzbTXJGp40easA= =Mlr+ -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030319094506.GB27330>