Hello everybody,
this is the first time I am posting here, so if there are any protocols
I should follow, just say so. Okay, now to the matter.
TL;DR: the min and max priority for SCHED_OTHER is -1 (both cases).
POSIX allows for whatever priority the system wants to define as min and
max when using SCHED_OTHER. In *NIX systems, when using SCHED_OTHER what
matters is the "niceness" of the process. However,
"sched_get_priority_{min,max}(SCHED_OTHER);" functions, which return the
value of the priority (-1 as stated before for NetBSD) use -1 as an
error code. So a min = max priority of -1 while "okay", is, by standard,
considered an error if a user program asks for it. However, after
further testing, I think that it can be left to -1 or at least accept
the value 0 too.
I am trying to update GNAT (gcc-ada/aux) in pkgsrc for NetBSD. I
stumbled on a roadblock, all tests that used tasks (Ada jargon for
threads) were failing with the same assertion error. After digging up a
bit I found they were failing when calling the function
"pthread_setschedparam". I looked at the inputs that were being sent and
they all seemed acceptable: the task, okay; the SCHED_ODER scheduling
system, ok?; and a priority of 15... ok? Long story short, I fixed a
problem with the SCHED_OTHER (it was erroneously imported into Ada), and
it still failed.
Since I did not know whether a priority of 15 was correct I looked it
up. I ended with this Stack Overflow question/answer [1]. I ran the code
to see the maximum and minimum values allowed by NetBSD with SCHED_OTHER:
- min: -1
- max: -1
Mmmm... Strange, those values, shouldn't they be positive, or at least
not -1? Lets see what "man sched_get_priority_min" says: "If successful,
the sched_get_priority_max() and sched_get_priority_min() functions
shall return the appropriate maximum or minimum values, respectively. If
unsuccessful, they shall return a value of -1 and set errno to indicate
the error."
Uf! Am I getting an error? Does NetBSD not allow the use of
SCHED_OTHER??? I went to the IRC chat and asked. As it happens, those
values are actually correct. NetBSD returns the value PRI_NONE, which is
-1. I created a horrible patch for GNAT, recompiled and it no longer
failed at that point! Yay!
However, I looked at how GNAT deals with priorities in Linux and found
out that it really does not care about what "pthread_setschedparam"
returns, even if it is an error. Why? Because when a process is using
SCHED_OTHER, since it is implementation defined, the process does not
care what happens. So if "pthread_setschedparam" fails for whatever
reason, it does not matter, it will keep on working.
So I really do not know what to say with this email apart from bringing
your attention to an indirect POSIX design violation. The issue is not
really with what you use as valid priorities (-1), since POSIX says it
is implementation defined. The problem is that if one gets the priority,
it receives an error as defined by POSIX, even though it is no error,
but the actual priority.
[1]
https://stackoverflow.com/questions/10657970/pthread-sched-get-priority-min-max-implementation-for-sched-other-sched-fifo
Regards,
Fernando Oleo Blanco
