From owner-freebsd-smp Tue Dec 8 00:22:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA28120 for freebsd-smp-outgoing; Tue, 8 Dec 1998 00:22:38 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA28090; Tue, 8 Dec 1998 00:22:32 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.8.8/8.8.8) with SMTP id IAA00509; Tue, 8 Dec 1998 08:22:01 GMT (envelope-from michaelh@cet.co.jp) Date: Tue, 8 Dec 1998 17:22:01 +0900 (JST) From: Michael Hancock To: Tony Kimball cc: tlambert@primenet.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP In-Reply-To: <13932.22397.480607.310372@avalon.east> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Dec 1998, Tony Kimball wrote: > 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. I think he's talking about stacks for kernel execution contexts (kernel threads). > : 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. Do you mean peculiarities that require you to do things like...? #ifdef SOLARIS25 thr_setconcurrency(2); #endif Digital UNIX is m-n and doesn't have these peculiarities and I thought they were resolved in Solaris 2.6. Regards, Mike Hancock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message