cvs commit: src/sys/kern uipc_socket.c

[John Baldwin]

On Wednesday 08 October 2008 02:16:45 am Robert Watson wrote:
> On Tue, 7 Oct 2008, John Baldwin wrote:
> 
> > On Tuesday 07 October 2008 04:57:55 pm Robert Watson wrote:
> >> rwatson     2008-10-07 20:57:55 UTC
> >>
> >>   FreeBSD src repository
> >>
> >>   Modified files:
> >>     sys/kern             uipc_socket.c
> >>   Log:
> >>   SVN rev 183675 on 2008-10-07 20:57:55Z by rwatson
> >>
> >>   In soreceive_dgram, when a 0-length buffer is passed into recv(2) and
> >>   no data is ready, return 0 rather than blocking or returning EAGAIN.
> >>   This is consistent with the behavior of soreceive_generic (soreceive)
> >>   in earlier versions of FreeBSD, and restores this behavior for UDP.
> >>
> >>   Discussed with: jhb, sam
> >>   MFC after:      3 days
> >
> > I do find this behavior odd though.  I would expect
> >
> > 	recv(fd, NULL, 0)
> >
> > to discard the next packet from the socket if one is available rather than 
> > returning success and not doing anything (and it seems that this is what 
it 
> > does both before and now).  Similarly, I would expect recv(fd, NULL, 0) to 
> > block on a blocking socket if there isn't a packet available.  It would be 
> > orthogonal then to return EAGAIN in this case (no packet available, 
> > zero-length user buffer) on a non-blocking socket.
> >
> > It seems that Solaris dropped this behavior (return 0) from their recv() 
> > system call sometime after SunOS 4.0 from comments in the OpenSolaris 
> > source. From reading __skb_recv_datagram(), it seems that Linux 2.6 
returns 
> > EAGAIN. NetBSD and OS X both have the odd behavior.  OpenBSD has the odd 
> > behavior, but with a caveat of sorts having to do with control messages. 
> > OpenBSD cvsweb annotate is down though, so I haven't found the reason for 
> > their change.
> 
> Yes, I agree it's odd, and I'm not sure I like it.  I discovered the problem 
> while writing edge-case regression tests for socket receive to better 
exercise 
> soreceive_dgram, at first concluding it was a bug in soreceive_generic!  My 
> feeling, though, is that I should leave behavior "compatible" for 7.1, and 
> perhaps we should change it for 7.2.

Ok, so I guess you will revert this from HEAD after the MFC?

-- 
John Baldwin