From owner-freebsd-stable Thu Mar 29 9:28:24 2001 Delivered-To: freebsd-stable@freebsd.org Received: from mail01.actzero.com (cpe-24-221-167-196.ca.sprintbbd.net [24.221.167.196]) by hub.freebsd.org (Postfix) with ESMTP id 45BB137B722 for ; Thu, 29 Mar 2001 09:28:21 -0800 (PST) (envelope-from blm@actzero.com) Received: by cpe-24-221-167-196.ca.sprintbbd.net with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Mar 2001 09:27:21 -0800 Message-ID: From: Brian Matthews To: "'freebsd-stable@freebsd.org'" Subject: Threads vs. blocking sockets Date: Thu, 29 Mar 2001 09:27:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I posted this to comp.unix.freebsd.misc then sent it to freebsd-questions, neither of which elicited any responses, so this is my court of last resort. :-)] 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. 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? Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message