Date: Thu, 7 Jun 2001 20:18:46 +0100 From: Graham Barr <gbarr@pobox.com> To: Alfred Perlstein <bright@rush.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: read(2) and ETIMEDOUT Message-ID: <20010607201846.E50444@pobox.com> In-Reply-To: <20010607150917.U1832@superconductor.rush.net>; from bright@rush.net on Thu, Jun 07, 2001 at 03:09:17PM -0400 References: <20010607171501.S50444@pobox.com> <20010607150917.U1832@superconductor.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 07, 2001 at 03:09:17PM -0400, Alfred Perlstein wrote: > * Graham Barr <gbarr@pobox.com> [010607 12:17] wrote: > > Since people seem to be helping you in other ways, I'll just > answer this one: > > > So, here is my question. Does anyone know under what circumstance > > ETIMEDOUT may be returned from read(2) or is this a potential bug > > somewhere ? > > I'm quite sure ETIMEDOUT is a result of hitting the setsockopt > SO_RCVTIMEO value when doing a read. I had been thinking along those lines too. But immediately before calling read, select said there was data to read, So it should not block, but read what data is there and return. Also why does this happen only every few hours ? There is a lot of data going through these connections maybe the timer for SO_RCVTIMEO is not being reset. But then we have another server, with a similar number of clients and data through put, but it does not suffer from this problem. As you can probably tell, we have been tearing our hair out over this one. Graham. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010607201846.E50444>