Date: Mon, 3 Jul 2006 08:08:56 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: John Birrell <jb@what-creek.com> Cc: threads@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: Strawman proposal: making libthr default thread implementation? Message-ID: <Pine.GSO.4.64.0607030803460.5928@sea.ntplx.net> In-Reply-To: <20060703120113.GA24614@what-creek.com> References: <20060703101554.Q26325@fledge.watson.org> <Pine.GSO.4.64.0607030744030.5823@sea.ntplx.net> <20060703120113.GA24614@what-creek.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Jul 2006, John Birrell wrote: > On Mon, Jul 03, 2006 at 07:48:43AM -0400, Daniel Eischen wrote: >> Yes, you have to support PTHREAD_PRIO_PROTECT, PTHREAD_PRIO_INHERIT >> mutexes, and SCHED_RR, SCHED_FIFO, and SCHED_SPORADIC scheduling >> (hopefully not under the restriction that you are a privileged user). > > How important are those relative to having libpthread work on other > architectures? It's not so much getting libpthread working on the other architectures (sparc64 is the only Tier 1 (is Sparc64 Tier 1 yet?) that libpthread doesn't work on). It's being able to support the POSIX standard. That was the goal years ago when we started the process of designing a new thread library. I maintain that we have to be able to support the standard, if we can't then it's a not a good design. > Are there any plans to get libpthread working on the other architectures? Someone with sparc64-fu will have to do some grunt work, but probably some can be grok'd from NetBSD (which also uses an SA approach). -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0607030803460.5928>