[EMAIL PROTECTED] wrote:
>
> In article
> <[EMAIL PROTECTED]>, Daniel
> Eischen <[EMAIL PROTECTED]> wrote:
>
> > For SCHED_FIFO and SCHED_RR, we don't have a problem because both
> > the threads library and kernel now agree that the range is 0..31.
> > SCHED_OTHER is a problem because the threads library treats
> > SCHED_OTHER as SCHED_RR with range 0..31. The kernel treats
> > SCHED_OTHER traditionally with range -20..20.
>
> As long as the only problem area is SCHED_OTHER, we are arguably
> OK. SCHED_OTHER is almost entirely implementation-defined; it can
> do practically anything. More specifically, section 13.5.2.2 (the
> detailed description of pthread_[sg]etschedparam) says:
>
> The policy parameter may have the value SCHED_OTHER, SCHED_FIFO,
> or SCHED_RR. The scheduling parameters for the SCHED_OTHER policy
> are implementation defined. The SCHED_FIFO and SCHED_RR policies
> shall have a single scheduling parameter sched_priority.
>
> I think it would be slightly less surprising if our implementation of
> SCHED_OTHER used thread priorities in the range -20..20 just the same
> as processes. But in my opinion POSIX doesn't require that.
I tend to agree. When you consider that you can mix
PTHREAD_SCOPE_SYSTEM threads with PTHREAD_SCOPE_PROCESS threads,
it seems logical that you'd want the priority ranges in both the
threads library and the kernel to agree. I would just rather
see 0..31 instead of -20..20.
We'll have to address this issue in the near future.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
