From owner-freebsd-arch Tue Nov 30 9:35:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4A24414DF3 for ; Tue, 30 Nov 1999 09:35:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA09133 for ; Tue, 30 Nov 1999 18:35:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71430 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 18:35:07 +0100 (MET) Received: from poboxer.pobox.com (ferg5200-1-3.cpinternet.com [208.149.16.3]) by hub.freebsd.org (Postfix) with ESMTP id 714F314DEC for ; Tue, 30 Nov 1999 09:34:56 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id LAA00420; Tue, 30 Nov 1999 11:34:48 -0600 (CST) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 30 Nov 1999 11:34:47 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: pulsifer@mediaone.net Cc: freebsd-arch@freebsd.org Subject: RE: Revisitted.. Threads goals.? References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14404.1860.533508.695941@avalon.east> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoth Allen Pulsifer on Tue, 30 November: : : The purpose of threads is to provide a more efficient method : of multitasking. Threads can't do anything that asynchronous I/O can't do for you better, in terms of throughput efficiency -- indeed, until threads execute in parallel, the distinction is merely one of API. : Implementation details aside, it seems to me that one : of the major points Matt Dillion is looking for is : the ability for two threads, bound to the same : process, to run simultaneously on two different : CPU's. It would defeat the value of the effort from my POV. I'm not an active contributor to this effort, but as for myself, the value of the effort lies in SMP performance portability, i.e. the ability to write scalable thread code that runs at throughput proportionate to hardware capability on a variety of systems, such as Solaris, Linux, IRIX, and FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message