Date: Mon, 7 Dec 1998 16:41:04 -0600 (CST) From: Tony Kimball <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 Message-ID: <13932.22397.480607.310372@avalon.east> References: <199812070443.MAA17869@spinner.netplex.com.au> <199812072216.PAA16574@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13932.22397.480607.310372>