Strawman proposal: making libthr default thread implementation?

[Peter Wemm]

On Mon, 3 Jul 2006, Daniel Eischen wrote:
> On Mon, 3 Jul 2006, David Xu wrote:
>
>> On Monday 03 July 2006 19:48, 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). 
>>>
>>
>> I would tell you don't implement system scope thread in libpthread,
>> because system scope thread does not work in the way you said here,
>> it seems you are telling user that the libpthread is fully working in
>> the way, but the reality is not, without a correct kernel support,
>> I don't think you should introduce system scope thread into
>> libpthread, please remove this feautre if you think libpthread should
>> work in the way. 
>
> I don't believe that system scope threads have to abide
> by SCHED_RR, SCHED_FIFO, and SCHED_SPORADIC scheduling
> since their contention scope is different.

It sounds like (by your definition) that switching to a libthr that only 
has system scope threads means we don't have to implement those modes, 
right?

My interest is reducing the performance cost with critical applications 
that are optimized for the assumption of a linux-like system-scope-only 
threading model.
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5