This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RLIMIT NICE in glibc


> 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 +++


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]