From owner-cvs-all@FreeBSD.ORG Wed Oct 8 19:10:52 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 758D61065688; Wed, 8 Oct 2008 19:10:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E3BE98FC18; Wed, 8 Oct 2008 19:10:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m98JAd6G057756; Wed, 8 Oct 2008 15:10:46 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Robert Watson Date: Wed, 8 Oct 2008 11:14:40 -0400 User-Agent: KMail/1.9.7 References: <200810072058.m97Kw3q0073534@repoman.freebsd.org> <200810071736.50999.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810081114.40433.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 08 Oct 2008 15:10:46 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8395/Wed Oct 8 12:44:51 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=4.2 tests=BAYES_00, DATE_IN_PAST_03_06, NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 19:10:52 -0000 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