From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 08:22:27 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B97616A4CF for ; Tue, 20 Jan 2004 08:22:27 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-89.apple.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88EF543D5F for ; Tue, 20 Jan 2004 08:22:13 -0800 (PST) (envelope-from justin@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i0KGMDqa024554 for ; Tue, 20 Jan 2004 08:22:13 -0800 (PST) Received: from mac.com (c-24-6-87-110.client.comcast.net [24.6.87.110]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id i0KGMB2k012086 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 20 Jan 2004 08:22:12 -0800 (PST) Date: Tue, 20 Jan 2004 08:22:09 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Justin Walker To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Subject: Re: send(2) does not block, send(2) man page wrong? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 16:22:27 -0000 On Monday, January 19, 2004, at 08:53 AM, Stuart Pook wrote: > The documentation for send(2) says > > If no messages space is available at the socket to hold the message > to be > transmitted, then send() normally blocks, unless the socket has been > placed in non-blocking I/O mode. The select(2) call may be used to > determine when it is possible to send more data. > > I cannot get send (or sendto which is what is really interests me) > to block on FreeBSD 4.9. When I send as fast as I can to a socket, > send rapidly fails with ENOBUFS. I am not surprised that the kernel is > running out of mbufs but I am surprised that send does not block until > more become available. > > Select does not block either. It always says that I can write to the > socket and then send fails with ENOBUFS. > > The udp_output function in /sys/netinet/udp_usrreq.c, seems clear: UDP does not have a need to block, so it does not. The UDP delivery 'promise' is best effort, and datagrams will get spilled anywhere along the route to the destination (no user crying over ...). If you use TCP, which has a need to block, your sending process will be blocked until both local and remote buffering space is available. You could make a case that the man page for 'send(2)' is either inaccurate or misleading. The problem is that 'send()' actually doesn't handle this; as your post indicates, the decision to block or fail a transmission is taken at the protocol level, and 'send()' is generally blind to that. Cheers, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | If you're not confused, | You're not paying attention *--------------------------------------*-------------------------------*