NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: Kamil Rytarowski <>
Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
 returning useful values
Date: Fri, 3 Aug 2018 18:14:44 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 Content-Type: multipart/mixed; boundary="h3HzcMaLZrklShAiHpG0YC7mlgCGCMUQ7";
 From: Kamil Rytarowski <>
 Message-ID: <>
 Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
  returning useful values
 References: <>
 In-Reply-To: <>
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable
 On 03.08.2018 16:55, Robert Elz wrote:
 > The following reply was made to PR lib/53495; it has been noted by GNAT=
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To:
 > Cc:=20
 > Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min n=
 ot 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 <>
 >      Message-ID:  <>
 > =20
 >    |  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 =
 >    |  other operations (unless setting a new one other than SCHED_OTHER=
 > =20
 >  I know even less about the realtime stuff than some of the other thing=
 s I
 >  comment about, but this does not seem to line up with some of the othe=
 >  test you quoted.   In particular ...
 > =20
 >  	 For threads executing under this policy, the implementation shall us=
 >  	 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.
 > =20
 >  which indicates, to me, that sched_get_priority_max() (and min) are re=
 >  to return sane results when passed SCHED_OTHER as a parameter.
 > =20
 >  Then it should be possible to use a value in the range [min,max] as th=
 >  sched parameter (which will be -1, of course, here .. aka PRIO_NONE)
 >  and everything should work.
 > =20
 >  Whether -1 is a sane valid result I am not sure.   The standard does n=
 >  say it cannot be.
 > =20
 We are returning -1 (PRI_NONE) as the returned value has to be a valid
 parameter passed to a routine changing scheduling policy with a
 requested priority level.
 "The value of the sched_priority member in the sched_param structure
 shall be any integer within the inclusive priority range for the
 scheduling policy specified by policy."
 -1 is already a valid value documented for a related function
 getpriority() and a user is encouraged to reset errno before the call.
 These features are different, however designed for a similar purpose.
 >  In this regard ...
 > =20
 > said:
 >    | it's also extremely awful to introduce more APIs that abuse errno =
 like you
 >    | suggest, and should not be done any time.=20
 > =20
 >  The API is not being introduced here, it is in POSIX, and so came from=
 >  somewhere else.
 > =20
 >  When whoever created it did so, I assume they assumed that legitimate
 >  priority results returned would all be >=3D 0, so that -1 as an error =
 made sense.
 > =20
 >  Whether POSIX restricts priority values to be >=3D 0 or not I have no =
 >  but I would not be surprised if not, to be more compatible with the an=
 >  nice() API (though with the sign reversed).   That is, they may allow
 >  implementations to support priority values that are < 0, and if so, ge=
 >  a (non-error) -1 result from these functions is entirely possible.
 > =20
 As noted above, this is true.
 >  And there is nothing we can do about it.
 > =20
 >  All that said, if PRIO_NONE is not already deeply ingrained as -1, it =
 >  not hurt to change it to be some other value, and make life easier (pe=
 rhaps -2)
 > =20
 We are already hardcoding -1 through the PRI_NONE symbol into existing
 executables. I don't think it's worth to change it. It's not a bug in
 the value.
 SCHED_OTHER has to be treated as an implementation specific priority
 level. We are requested to just ship it without being fully defined.
 A portable code shall not make any assumptions about it, except those
 Linux has a different implementation and people treat is similarly to
 SCHED_RR, without testing on all modern OSes. There is a small number of
 programs that need adjusting (I've encountered like up to 5 of them).
 >  kre
 > =20
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"

Home | Main Index | Thread Index | Old Index