Date: Wed, 8 Oct 2008 07:16:45 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c Message-ID: <alpine.BSF.1.10.0810080714290.91071@fledge.watson.org> In-Reply-To: <200810071736.50999.jhb@freebsd.org> References: <200810072058.m97Kw3q0073534@repoman.freebsd.org> <200810071736.50999.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0810080714290.91071>