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