cvs commit: src/sys/netinet sctp_bsd_addr.c

Bruce Evans brde at optusnet.com.au
Mon Dec 31 21:37:31 PST 2007


On Mon, 31 Dec 2007, M. Warner Losh wrote:

> In message: <200712311219.08286.jhb at freebsd.org>
>            John Baldwin <jhb at FreeBSD.org> writes:

> : The more correct fix though is to do a 'sched_prio()' at the start of the
> : thread's main loop to set the priority and then not adjust it via msleep().
> : Kernel threads really should never pass a priority to msleep() but always '0'
> : (which means "don't change my priority").
>
> Not PZERO?  When should one use PZERO and when should one use a bare
> '0'?  Can this information be added to the man page?

PZERO is compatibility cruft which should never be used.  Just a few
places in kern still use it to invent a priority when no suitable
priority (like PSOCK or PRIBIO) is already #defined.  It isn't clear
where these invented priorities are suitable.

Otherwise, PZERO has a completely different meaning from either priority
0 (maximal) or the bare 0 arg to msleep.  It means some middle priority,
or the bias from priority 0 to get to that middle priority, so that
after subtracting it, 0 becomes the middle priority.  The bare 0 is
actualy priority 0 (maximal) overloaded to mean "don't change the
priority".  This overloading doesn't lose anything except clarity since
nothing is permitted to wake up at maximal priority after a sleep.
(Maximal priority is reserved for realtime priority ithreads and even
much lower priority ithreads are not permitted to sleep, and non-interrupt
threads aren't permitted to run at ithread priorities except temporarily
for priority propagation.)

Bruce


More information about the cvs-src mailing list