In article <7e349617-70c3-6eac-b865-41a378693...@irvise.xyz>, Fernando Oleo Blanco <irvise...@irvise.xyz> 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