In article <7e349617-70c3-6eac-b865-41a378693...@irvise.xyz>,
Fernando Oleo Blanco wrote:
>[[Resending from tech-userlevel as per recommendation from Reinoud]]
>
>
>Hello everybody,
>
>
>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.
You can differentiate between (-1 + error), and (-1 + valid value). by checking
errno. The same is true for strtol("-1", NULL, 10). Yes, it is ugly because
you need to set errno to 0 before the call, but it is doable. In retrospect
we should have chosen a different value to return, but it is going to be
disruptive to change.
Best,
christos
