Date: Fri, 25 Apr 2003 03:21:18 +0200 (CEST) From: Dirk-Willem van Gulik <dirkx@webweaving.org> To: freebsd-hackers@freebsd.org Subject: recv() returning 0 and EINTR on a still connection. Message-ID: <20030425031450.G8323-100000@foem.leiden.webweaving.org>
next in thread | raw e-mail | index | archive | help
After an upgrade from 2.2.8 to 5.0 the following fragement of
code in userland seems to trip under high loads:
server-code
n = recv(...
if (n<0) {
if (errno = EAGAIN)
..
if (errno = EINTR)
..
}
if (n == 0)
bing
with a n == 0 and errno == EINTR. (i.e. NOT n=-1).
Even though the connection does not seem closed from the client end.
Is it possible for n==0 -not- to mean that the connection is closed ?
Or in other words that recv() behaves not like read(2) in this respect.
(In all fairness; the man page for recv(2) does only detail n=-1 for the
EAGAIN. And does not mention any semantics for n==0, unlike read(2) which
says:
RETURN VALUES
If successful, the number of bytes actually read is returned. Upon read-
ing end-of-file, zero is returned. Otherwise, a -1 is returned and the
global variable errno is set to indicate the error.
Is recv() fundamentally different ? And is n==0 errno=EINTR a possible
valid return with the meaning; interupted and no bytes read ?
Thanks
Dw
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030425031450.G8323-100000>