From owner-freebsd-stable  Sat Mar 31  4:21:28 2001
Delivered-To: freebsd-stable@freebsd.org
Received: from mutsaers.com (dubkurdsp503.agrinet.ch [212.232.160.3])
	by hub.freebsd.org (Postfix) with ESMTP id D9C0437B718
	for <freebsd-stable@freebsd.org>; Sat, 31 Mar 2001 04:21:23 -0800 (PST)
	(envelope-from plm@mutsaers.com)
Received: (from plm@localhost)
	by mutsaers.com (8.11.1/8.11.1) id f2UHvHD04965;
	Fri, 30 Mar 2001 19:57:17 +0200 (CEST)
	(envelope-from plm)
To: freebsd-stable@freebsd.org
Subject: Re: Threads vs. blocking sockets
From: Peter Mutsaers <peter@mutsaers.com>
Date: 30 Mar 2001 19:57:17 +0200
In-Reply-To: Brian Matthews's message of "Thu, 29 Mar 2001 12:40:06 -0800"
Message-ID: <87puezb0n6.fsf@mutsaers.com>
Lines: 39
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>> "Brian" =3D=3D Brian Matthews <blm@actzero.com> writes:

    Brian> | Again, all threading libraries I've used (not just on=20
    Brian> | FreeBSD) *require*
    Brian> | the user to check that when sending/receiving data, the=20
    Brian> | caller must make
    Brian> | sure that all the expected data has been sent/received.

    Brian> Linux doesn't, and I don't think Solaris does (we just
    Brian> moved so I can't try it now, but when I was investigating
    Brian> the problem I'm pretty sure I tried it on our Sun
    Brian> box). Also, it means that threaded Python is basically
    Brian> useless for doing HTTP stuff, as the standard Python
    Brian> library httplib assumes send sends everything or fails
    Brian> (which is how I originally found the problem), and it looks
    Brian> like perl does the same thing.

Any program assuming that send() or write() on a TCP socket writes all
data is broken.

Look in any decent book on socket programming, everywhere you'll find
the standard 'wrapping' of basic send() like:

int n=3Dlength;
while (n>0) {
        n-=3Dsend(sock, msg-length+n, n, flags);
}

This has nothing to do even with threads. It goes for any socket also
in non-threaded environments.

When the tcp-send buffers are full, it will happen. There may be other
causes. I know there used to be many systems that would not send more
than the phisical packet size of the network used (i.e. send's return
value would never be more than 1500 on ethernet, or 4k on token ring).

--=20
Peter Mutsaers  |  D=FCbendorf    | UNIX - Live free or die
plm@gmx.li      |  Switzerland  | Sent via FreeBSD 4.2-stable

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message