From owner-freebsd-smp Mon Dec 7 14:43:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA26574 for freebsd-smp-outgoing; Mon, 7 Dec 1998 14:43:18 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA26561; Mon, 7 Dec 1998 14:43:03 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.1/8.9.1) id QAA60351; Mon, 7 Dec 1998 16:41:05 -0600 (CST) (envelope-from alk) From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 Dec 1998 16:41:04 -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: tlambert@primenet.com Cc: peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP References: <199812070443.MAA17869@spinner.netplex.com.au> <199812072216.PAA16574@usr06.primenet.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13932.22397.480607.310372@avalon.east> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoth Terry Lambert on Mon, 7 December: : One reason I haven't piped up on this (I *do* have the scheduler : changes for CPU affinity working, actually) is that apart from : that, there's still the issue of the per thread stack. : : I am not very satisfied nor happy with the allocation of stack in : the same VM space in each thread (for reasons of stack autogrowth), : and I would want to address that before anything else. Yikes! Surely you are not proposing to place the stacks of distinct threads in distinct address spaces?! This would impact application portability negatively. : Finally, apart from affinity, kernel threads are relatively useless : as an implementation without cooperative user space scheduling. : The only OS which I am aware of having addressed these isses at : this point is Solaris. Give me 1-1 threads, thank you very much, and I will be most happy to manage my own task pools, as this is the only way to write portably in the current state of play. 'Relatively useless' is an overstatement of the case. Relatively useless, perhaps, for the case of Solaris applications relying upon the peculiarities of Solaris thread semantics. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message