> In article
> 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 (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
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

Reply via email to