[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #18883] nice/getpriority/setpriority enforces even nice values
From: |
Samuel Thibault |
Subject: |
[bug #18883] nice/getpriority/setpriority enforces even nice values |
Date: |
Thu, 25 Jan 2007 23:22:20 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20061219 Iceape/1.0.7 (Debian-1.0.7-2) |
URL:
<http://savannah.gnu.org/bugs/?18883>
Summary: nice/getpriority/setpriority enforces even nice
values
Project: The GNU Hurd
Submitted by: sthibaul
Submitted on: vendredi 26.01.2007 à 00:22
Category: glibc
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Standard Compliance
Status: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Reproducibility: Every Time
Size (loc): None
Planned Release: None
Effort: 0.00
Wiki-like text discussion box:
_______________________________________________________
Details:
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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?18883>
_______________________________________________
Message posté via/par Savannah
http://savannah.gnu.org/
- [bug #18883] nice/getpriority/setpriority enforces even nice values,
Samuel Thibault <=