Re: [bug #18883] nice/getpriority/setpriority enforces even nice values

[olafBuddenhagen]

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-