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 <net@FreeBSD.ORG>; 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 <rizzo@aciri.org>
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