[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: olafBuddenhagen
Subject: Re: [bug #18883] nice/getpriority/setpriority enforces even nice values
Date: Sat, 27 Jan 2007 15:26:47 +0100
User-agent: Mutt/1.5.13 (2006-08-11)


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
> 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...)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]