From owner-freebsd-stable Thu Mar 29 13:54:15 2001 Delivered-To: freebsd-stable@freebsd.org Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by hub.freebsd.org (Postfix) with ESMTP id F1A0437B718 for ; Thu, 29 Mar 2001 13:54:08 -0800 (PST) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id AUS14219; Fri, 30 Mar 2001 00:53:49 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.11.3/8.11.3) id f2TLqh702066; Fri, 30 Mar 2001 00:52:43 +0300 (EEST) (envelope-from netch) Date: Fri, 30 Mar 2001 00:52:43 +0300 From: Valentin Nechayev To: Brian Matthews Cc: "'freebsd-stable@freebsd.org'" Subject: Re: Threads vs. blocking sockets Message-ID: <20010330005243.A298@iv.nn.kiev.ua> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from blm@actzero.com on Thu, Mar 29, 2001 at 09:27:20AM -0800 X-42: On Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thu, Mar 29, 2001 at 09:27:20, blm (Brian Matthews) wrote about "Threads vs. blocking sockets": > I was encountering some problems using sockets on FreeBSD. After some > exploration I've found that threading doesn't seem (at least in my opinion) > to handle blocking sockets correctly. Specifically, calls to send (and > presumably recv, although so far I've only doing recvs on nonblocking > sockets) on a blocking socket may return having only transferred part of the > data. It is not correct even in case of single-threaded program. Consider, for example, a case when waiting on blocking call is interrupted with signal. If send() already transferred some data, it will return number of bytes sent. If none data transferred, it will return -1 and EINTR in errno. If you rely on sending all data in send() without checking, your code is buggy. > As the standard FreeBSD threads are user space, they obviously can't let the > socket call really block, so behind the scenes all sockets are created as > nonblocking. However, I would then expect the threaded versions of the data > transfer calls (send*, etc.) to loop over the actual system calls. They > actually do so to catch EWOULDBLOCK/EAGAIN (see > /usr/src/lib/libc_r/uthread/uthreads_sendto.c for example), but don't to > make sure all the requested data is transferred. This seems to me like a > bug. > > Thoughts, comments? Amount of data sent is implementation-, environment- and randomness-dependent. Your current code works in 99.9% cases, but it is buggy. Fix it. /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message