At Sun, 17 Apr 2005 00:05:53 +0200,
Soeren D. Schulze wrote:
> after running the test script myself and thinking I a bit, I found the
> reason why it fails:
>
> Coreutils nice expects a priority range from 0 to 39 (mapped to -20..19
> for the user) but Mach only provides 0..31.
I think you mean: the coreutils test suite assumes that if you
successfully set a process's nice value then the value you get back
from calling getpriority will be the value you set. Reading POSIX,
this is a fairly reasonable expectation which we don't meet.
Given this problem, what should we do if anything at all? If the only
program which relies on this behavior is the core utils' test suite
then we could ignore it. I doubt other programs do as calling nice
and then getpriority is not atomic. As such, between the two calls an
external process could have reniced the process.
> My proposal is to change the mapping policy and map 0..39 to 0..31
> discarding the 8 lowest possible priorites. Priorities below the
> default priority (0 to the user) do not work properly anyway right now.
> Once they work, it will not hurt too badly if the range is only partly
> accessible.
What a nice value means is implementation defined. Thus any POSIX
program (without knowledge of the Hurd) cannot rely on it to have any
particular meaning. As such, we can change the meaning whenever we
want without affecting POSIX programs (i.e. it would affect only those
that rely on the Hurd's implementation of POSIX).
But your proposal only fixes a corner case: you still have the problem
that for some priority values, getpriority will return a difference
nice value than which was supplied to nice.
> On IRC, Neal had come up with another proposal for a change in the libc
> POSIX layer that uses a kind of caching, but I had not really
> understood.
> Neal, could you state your idea here to everyone?
My suggestion was to save the nice value and the corresponding Mach
priority when nice or setpriority is called. Then when getpriority is
called if the current Mach priority is the same as the saved Mach
priority, return the saved nice value.
int saved_nice_value;
int saved_priority;
setpriority (priority)
{
saved_nice_value = priority;
saved_mach_priority = NICE_TO_MACH (priority);
task_policy (... mach_priority ...);
}
getpriority ()
{
int mach_priority = get current mach priority;
if (mach_priority == saved_mach_priority)
return nice_value;
return MACH_TO_NICE (mach_priority);
}
Frankly, I don't know if any fix is generally useful as the problem
seems negligible.
Thanks,
Neal
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
