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