Re: lib/53495: sched_get_priority_max/sched_get_priority_min not returning useful values

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR lib/53495; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not returning useful values
Date: Fri, 03 Aug 2018 21:54:03 +0700

     Date:        Fri,  3 Aug 2018 13:20:01 +0000 (UTC)
     From:        Kamil Rytarowski <n54%gmx.com@localhost>
     Message-ID:  <20180803132001.28AE77A1F9%mollari.NetBSD.org@localhost>
 
   |  According to my understanding the proper fix to the Thomas' code is to
   |  check type of scheduling policy, if it is SCHED_OTHER - bail out from
   |  other operations (unless setting a new one other than SCHED_OTHER).
 
 I know even less about the realtime stuff than some of the other things I
 comment about, but this does not seem to line up with some of the other
 test you quoted.   In particular ...
 
 	 For threads executing under this policy, the implementation shall use
 	 only priorities within the range returned by the
 	 sched_get_priority_max() and sched_get_priority_min() functions when
 	 SCHED_OTHER is provided as the parameter.
 
 which indicates, to me, that sched_get_priority_max() (and min) are required
 to return sane results when passed SCHED_OTHER as a parameter.
 
 Then it should be possible to use a value in the range [min,max] as the
 sched parameter (which will be -1, of course, here .. aka PRIO_NONE)
 and everything should work.
 
 Whether -1 is a sane valid result I am not sure.   The standard does not
 say it cannot be.
 
 In this regard ...
 
 mrg%eterna.com.au@localhost said:
   | it's also extremely awful to introduce more APIs that abuse errno like you
   | suggest, and should not be done any time. 
 
 The API is not being introduced here, it is in POSIX, and so came from
 somewhere else.
 
 When whoever created it did so, I assume they assumed that legitimate
 priority results returned would all be >= 0, so that -1 as an error made sense.
 
 Whether POSIX restricts priority values to be >= 0 or not I have no idea,
 but I would not be surprised if not, to be more compatible with the ancient
 nice() API (though with the sign reversed).   That is, they may allow
 implementations to support priority values that are < 0, and if so, getting
 a (non-error) -1 result from these functions is entirely possible.
 
 And there is nothing we can do about it.
 
 All that said, if PRIO_NONE is not already deeply ingrained as -1, it would
 not hurt to change it to be some other value, and make life easier (perhaps -2)
 
 kre