Date: Mon, 26 Jan 2004 11:16:22 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Julian Elischer <julian@elischer.org> Cc: Stuart Pook <Stuart.Pook@infres.enst.fr> Subject: Re: send(2) does not block, send(2) man page wrong? Message-ID: <20040126111622.A96082@xorpc.icir.org> In-Reply-To: <Pine.BSF.4.21.0401261052590.76985-100000@InterJet.elischer.org>; from julian@elischer.org on Mon, Jan 26, 2004 at 10:53:54AM -0800 References: <E1Al8xj-0002aR-00@roo> <Pine.BSF.4.21.0401261052590.76985-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040126111622.A96082>