Date: Sat, 31 May 2003 09:27:28 +0300 From: "Petri Helenius" <pete@he.iki.fi> To: "Matthew D. Fuller" <fullermd@over-yonder.net>, "Daniel Eischen" <eischen@pcnet.com> Cc: threads@freebsd.org Subject: Re: Transition plans: libkse->libpthread Message-ID: <00c401c3273d$b59a9140$812a40c1@PETEX31> References: <Pine.GSO.4.10.10305301945590.10348-100000@pcnet5.pcnet.com> <20030531024932.GP61246@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> >From my comfortable position here in the peanut gallery, I've been
> thinking about this. Now that we have libthr around (presumably for a
> long time), mightn't it be a good idea to keep libkse and libkse, libthr
> and libthr, and maybe even libc_r as libc_r, and have libpthread be a
> {sym,hard}link to one of the above? Since we're ending up with multiple
> libraries implementing the pthreads API, with the presumption that
> they're at least nominally interchangeable, might we not want to make
> that switchability explicit?
>
>From where Iīm looking at this (pthreads user) I donīt see value retaining
libc_r longer than neccessary for backwards compability. FreeBSD would
benefit greatly having the "default" threads implementation to be well performing
and using all available CPU on a machine.
What are the observed benefits on running a threaded application with 1:1
threads instead of the M:N libkse model? And if you need more scheduled
entities, wouldnīt you just crank up the concurrency parameter?
Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00c401c3273d$b59a9140$812a40c1>