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

William Michael Grim wgrim at siue.edu
Thu Apr 24 23:13:01 PDT 2003


Hey there.

I think your problem is that n==0 does NOT mean the connection was closed
(at least not with TCP; I haven't really looked into other session
protocols).

If n==0, it only means you have stopped receiving data because there is no
more to be received; you can only trust errno if n==-1 or whatever the man
page specifies for your OS (FreeBSD is -1 in this case).

I hope this helps you unless I somehow misread anything you said.

William Michael Grim
Student, Southern Illinois University at Edwardsville
Unix System Administrator, SIUE, Computer Science dept.
Phone: (217) 341-6552
Email: wgrim at siue.edu



On Fri, 25 Apr 2003, Dirk-Willem van Gulik wrote:

> 
> 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
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 



More information about the freebsd-hackers mailing list