Date: Wed, 19 Mar 2003 11:58:42 +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: <20030319095842.GC27330@straylight.oblivion.bg> In-Reply-To: <20030319094506.GB27330@straylight.oblivion.bg> References: <20030319093002.GT468@straylight.oblivion.bg> <20030319013748.A84035@xorpc.icir.org> <20030319094506.GB27330@straylight.oblivion.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
--H1spWtNR+x+ondvy Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2003 at 11:45:06AM +0200, Peter Pentchev wrote: > 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 any= one > >=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. >=20 > 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. >=20 > 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?). >=20 > > Sounds like the correct approach is to set the handler for > > SIGPIPE to sig_ign >=20 > This would work, but is somewhat besides the point IMHO. >=20 > > 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. >=20 > 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. Actually, I wonder if I have answered my own question. dnscache seems to use poll(2), and it would be poll(2)'s task to notify the program of any exceptional (error) conditions. I wonder if it is possible that dnscache does not handle POLLERR properly... Let me check. 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 Do you think anybody has ever had *precisely this thought* before? --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+eD9S7Ri2jRYZRVMRAhmsAJ9buEeyiRm0N4kwld9tRu8TK4Q2+wCeN1Wn SQGu/NixCbHwrbNbIsjd7+c= =M9hd -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- 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?20030319095842.GC27330>