From owner-freebsd-hackers Sun Dec 19 9:22:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 72D20151CF for ; Sun, 19 Dec 1999 09:22:19 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id JAA01832; Sun, 19 Dec 1999 09:22:18 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA28697; Sun, 19 Dec 1999 09:22:17 -0800 (PST) (envelope-from jdp@polstra.com) Date: Sun, 19 Dec 1999 09:22:17 -0800 (PST) Message-Id: <199912191722.JAA28697@vashon.polstra.com> To: dcs@newsguy.com Subject: Re: Practical limit for number of TCP connections? In-Reply-To: <385CEE25.5239137E@newsguy.com> References: <43033.945551665@monkeys.com> <385CEE25.5239137E@newsguy.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <385CEE25.5239137E@newsguy.com>, Daniel C. Sobral wrote: > "Ronald F. Guilmette" wrote: > > > As I say, my understanding is that FreeBSD still doesn't have real > > and/or complete thread support in the kernel. So if you have a > > multi-threaded application and one thread blocks (e.g. on I/O) > > then the whole thing is blocked. [...] > Not to dismiss FreeBSD's kernel problems, but that thing about > blocking is absurdly untrue. It is in fact partially true. If a thread blocks on disk I/O then the whole process (all threads) blocks. That can be significant for applications that are disk intensive. I believe it to be the most significant bottleneck in current versions of CVSup, for example. (CVSup doesn't use FreeBSD's threads library, but it uses Modula-3's built-in threads package which is similar in design.) Once our aio support is knocked into shape, it should be possible for userland threads packages to use that in preference to select(). Then threads could run while one or more others were blocked on disk I/O. Of course kernel thread support may improve soon enough so that this approach isn't necessary. For CVSup I plan to experiment with using a small farm of disk I/O subprocesses (processes, not threads), communicating with the master process via shared memory and/or pipes. Without trying it, I can't say for sure whether it will yield a net win or a net loss in speed. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message