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

[Kamil Rytarowski <n54%gmx.com@localhost>]

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

From: Kamil Rytarowski <n54%gmx.com@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, 3 Aug 2018 18:14:44 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --IDt3wyhaIzaLB3FYNH0UP8jSph530VhKq
 Content-Type: multipart/mixed; boundary="h3HzcMaLZrklShAiHpG0YC7mlgCGCMUQ7";
  protected-headers="v1"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: gnats-bugs%NetBSD.org@localhost
 Message-ID: <f302210b-9ee6-428a-8dd2-e36db9ad395b%gmx.com@localhost>
 Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
  returning useful values
 References: <pr-lib-53495%gnats.netbsd.org@localhost>
  <20180802213550.3008D2AC0E7%yt.nih.at@localhost>
  <20180803145501.A148F7A1F7%mollari.NetBSD.org@localhost>
 In-Reply-To: <20180803145501.A148F7A1F7%mollari.NetBSD.org@localhost>
 
 --h3HzcMaLZrklShAiHpG0YC7mlgCGCMUQ7
 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=
 S.
 >=20
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > 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
 >=20
 >      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>
 > =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 =
 from
 >    |  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=
 r
 >  test you quoted.   In particular ...
 > =20
 >  	 For threads executing under this policy, the implementation shall us=
 e
 >  	 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=
 quired
 >  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=
 e
 >  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=
 ot
 >  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."
 
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_setschedu=
 ler.html#
 
 -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
 >  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.=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 =
 idea,
 >  but I would not be surprised if not, to be more compatible with the an=
 cient
 >  nice() API (though with the sign reversed).   That is, they may allow
 >  implementations to support priority values that are < 0, and if so, ge=
 tting
 >  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 =
 would
 >  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
 specified.
 
 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
 >=20
 
 
 
 --h3HzcMaLZrklShAiHpG0YC7mlgCGCMUQ7--
 
 --IDt3wyhaIzaLB3FYNH0UP8jSph530VhKq
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 
 iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAltkf3QMHG41NEBnbXgu
 Y29tAAoJEEuzCOmwLnZsfCcP/RAqnQ2Kan66zzyvDHT7OyE9+td1jJSjUzfybJvQ
 qj2F+Pgebb5eEVT2uvVv2GQJbKZXmISmhGFACuSCqGlRMLpOrBORft3NLV+1O4es
 +Szm3CP5i0eVPy1qlXGsGY7m0qRKc0EX9LmTJ0xzU9cMHtveuv9xW1qv0nXf+bC4
 4bOxdg1t1wqtme1ZV9IYH+odCmmfTnA/xEXVWv080xKRNm3nSz6gGr93END0EPD7
 pAeZuti1bLNlbF9q4w8KA+RqL/XtoDOwF0u+j12DCtbefPCu0seugRAqXrKcyA/A
 N89GdAj/FuuZaDtUhD0p+YkvvZzuUD8do9HzInFu+xlbMzSDlDnFIu/DhVcDMGT/
 uFm+LceomlOqQiLzQgShQZocPZrc9Yx1co3lk0Kh2QNWBgAN69ZHjpbA4XgTnRuf
 49kRHfiqa46TTgswuhh7c86+hlNB/kZqNwgO1NMovOWx81hRgUSqkR1GrveFvgz2
 wmrcuEXKLXyEU5amKmL/WlgTrzIuAOBkTH6+gGFn+6S0WiB70Yk/d/kCqX8tfNtb
 1k+AXrtgk4oVWUJESuxwMwxwxR7PHwnEjNvodmfBo86IQmzZojbBfRL8BvKrAKvO
 qAO3ZRpsn9g6nkPU83sjPp4rDJt8opxd31g4+G1YqBw7I7u9oZVrcUebp3e/IrU5
 +tnr
 =qBsg
 -----END PGP SIGNATURE-----
 
 --IDt3wyhaIzaLB3FYNH0UP8jSph530VhKq--