Date: 30 Mar 2001 19:57:17 +0200 From: Peter Mutsaers <peter@mutsaers.com> To: freebsd-stable@freebsd.org Subject: Re: Threads vs. blocking sockets Message-ID: <87puezb0n6.fsf@mutsaers.com> In-Reply-To: Brian Matthews's message of "Thu, 29 Mar 2001 12:40:06 -0800"
next in thread | raw e-mail | index | archive | help
>> "Brian" == Brian Matthews <blm@actzero.com> writes:
Brian> | Again, all threading libraries I've used (not just on
Brian> | FreeBSD) *require*
Brian> | the user to check that when sending/receiving data, the
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=length;
while (n>0) {
n-=send(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).
--
Peter Mutsaers | Dübendorf | 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87puezb0n6.fsf>