From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 26 11:16:39 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 3C7C516A4CE; Mon, 26 Jan 2004 11:16:39 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D3B543D1D; Mon, 26 Jan 2004 11:16:29 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i0QJGMAF096300; Mon, 26 Jan 2004 11:16:22 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i0QJGMGT096299; Mon, 26 Jan 2004 11:16:22 -0800 (PST) (envelope-from rizzo) Date: Mon, 26 Jan 2004 11:16:22 -0800 From: Luigi Rizzo To: Julian Elischer Message-ID: <20040126111622.A96082@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Mon, Jan 26, 2004 at 10:53:54AM -0800 cc: freebsd-hackers@freebsd.org cc: Don Lewis cc: andre@freebsd.org cc: Stuart Pook 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: Mon, 26 Jan 2004 19:16:39 -0000 On Mon, Jan 26, 2004 at 10:53:54AM -0800, Julian Elischer wrote: ... > On Mon, 26 Jan 2004, Stuart Pook wrote: > > > > On 23 Jan 2004, Don Lewis wrote: > > > > the send does not give an error: the packet is just thrown away. > > > > > > Which is the same result as you would get if the bottleneck is just one > > > network hop away instead of at the local NIC. > > > > But it isn't. I'm broadcasting onto the local network. With Linux and > > Solaris (which implement what FreeBSD send(2) says), it is so easy: I just > > send(2) away, and because the send blocks when the kernel buffer space is I'd be really curious to know how Linux/Solaris actually implement this blocking send and if they really block or use some kind of timeout/retry loop in the kernel. To implement a blocking send() on UDP sockets, you need a different driver model from the one we have, one where sockets and other data sources trying to access a full interface queue should be queued into some kind of list hanging off the interface, so that when the interface is ready again you can wake up the pending clients in turn and process their requests. This would cause the output queue to become effectively unbounded (basically, it is like reserving at least one slot per socket -- more if you want to deal with fragments), and even if the slot can be allocated as part of the socket, the delay would become unbounded as well. Secondly, if the interface for some reason goes "temporarily" down (e.g. no-carrier or the like) the process would suddenly block unless you mark the socket as non blocking. cheers luigi