recv() returning 0 and EINTR on a still connection.

[Dirk-Willem van Gulik]

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