Hi,
On Thu, Jan 25, 2007 at 11:22:20PM +0000, Samuel Thibault wrote:
> Because of limitation of the Mach kernel, nice values are divided by
> two for getting a Mach priority (MACH_PRIORITY_TO_NICE), and mach
> priority is multiplied by two for getting a nice value
> (NICE_TO_MACH_PRIORITY).
>
> That makes setpriority/getpriority/nice behave strangely: they enforce
> an even nice value, which makes the corutils package's testsuite fail.
>
> The POSIX standard says ``The nice() function shall add the value of
> incr to the nice value of the calling process.'' and ``Upon successful
> completion, nice() shall return the new nice value - {NZERO}.''
>
> Does glibc need corrected or the testsuite fixed to accept such a
> behavior? I'd say glibc should be corrected, keeping the nice value in
> a global variable.
AFAIK Sören Schulze once implemented such a workaround, after there has
been lots of talk about it; but once he did, nobody was interested in
reviewing it.
However, I don't think this is the right approach really. Isn't it
easier to fix gnumach to allow enough priority levels for a 1:1 mapping?
OTOH, nice on the Hurd is broken in such an amazing number of ways, that
I seriously doubt whether it's worth touching at all, unless you
completely redo it. (Preferably by changing the Mach interface to
something more approriate for implementing UNIX-like semantics...)
-antrik-
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
