Date: Tue, 8 Dec 1998 17:22:01 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Tony Kimball <alk@pobox.com> Cc: tlambert@primenet.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP Message-ID: <Pine.BSF.3.95LJ1.1b3.981208170921.370A-100000@sv01.cet.co.jp> In-Reply-To: <13932.22397.480607.310372@avalon.east>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95LJ1.1b3.981208170921.370A-100000>