RLIMIT NICE in glibc
Michael Kerrisk
michael.kerrisk@gmx.net
Tue Sep 20 09:59:00 GMT 2005
> Von: Roland McGrath <roland@redhat.com>
>
> It is certainly a bad idea to have glibc interject any special magic
> between your setrlimit/getrlimit calls and the kernel.
> It is certainly a bad idea to have glibc interject any special magic
> between your setrlimit/getrlimit calls and the kernel.
As things stand, we have this situation:
+----<---- setpriority() ----------<-------+
kernel / syscall \
nice / \ userland
range / \ range
19..-20 o--> getpriority() --> 1..40 --> getpriority() -->-o 19..-20
^ syscall glibc wrapper
| returns (20 Â nice) returns (20 Â res)
|
kernel/sched.c:can_nice()
checks that
nice >= 20 - RLIMIT_NICE_value
|
|
V
kernel RLIMIT_NICE userland RLIMIT_NICE
range range
1..40 o------<--->-------- getrlimit() / -------<--->------o 1..40
setrlimit() syscalls
Having two different ranges for values that are semantically
related is unfortunate.
And I'd been thinking that inserting special magic is exactly
what the getpriority() glibc wrapper already does already
does -- to allow the kernel to avoid the problem of negative
syscall return values.
So I had been thinking that getrlimit() / setrlimit() wrappers in
glibc might be desirable to avoid the dual-representation issue.
However, I overlooked something: using a negative range for
RLIMIT_NICE values in userland won't work because RLIM_INFINITY
(and similar) are represented as constants such as ~0UL. (In
other words, there are userland constraints on the range that
RLIMIT_NICE must deal with, whereas there are no such
constraints for getpriority().)
So in summary -- my idea looks unworkable anyway.
Cheers,
Michael
--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++
More information about the Libc-alpha
mailing list