From owner-freebsd-net Wed Feb 7 11: 9: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1E53337B491 for ; Wed, 7 Feb 2001 11:08:49 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f17J8mr77641; Wed, 7 Feb 2001 11:08:48 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102071908.f17J8mr77641@iguana.aciri.org> Subject: Re: send problem on udp socket... In-Reply-To: <20010207105906.O26076@fw.wintelcom.net> from Alfred Perlstein at "Feb 7, 2001 10:59: 6 am" To: bright@wintelcom.net (Alfred Perlstein) Date: Wed, 7 Feb 2001 11:08:48 -0800 (PST) Cc: rizzo@aciri.org, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Since this is UDP, I'm not sure much should be done, perhaps > just document the return value, but honestly since it's _U_DP exactly -- documenting is the only thing we can do. There are far too many apps that might break if we change this behaviour. Ideally one could add a setsockopt to implement a truly blocking behaviour on sockets where there is not an explicit underlying flow control scheme, but flow control info can still be derived by other means. > it could just easily fail silently as long as local datagrams > are allowed to be lossy. i am not much concerned about this, but rather by the fact that those apps which want to send as fast as possible have no better way than looping around a non-blocking call, whereas it would be much more efficient to pass signals up. Next life... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message