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 15:18:40 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --ibdZQT2m5JkcugrGH6aF6tg5Bct1G1Otc
 Content-Type: multipart/mixed; boundary="eovONmXsGAD9VV3gbLdacQBnYSUE5VL5Q";
  protected-headers="v1"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: gnats-bugs%NetBSD.org@localhost
 Message-ID: <f7079230-b284-ad03-76e2-0d4749689f4b%gmx.com@localhost>
 Subject: Re: lib/53495: sched_get_priority_max/sched_get_priority_min not
  returning useful values
 References: <12733.1533280044%splode.eterna.com.au@localhost>
  <71bf3c01-8975-8828-08ce-6636199d9f7a%gmx.com@localhost>
 In-Reply-To: <71bf3c01-8975-8828-08ce-6636199d9f7a%gmx.com@localhost>
 
 --eovONmXsGAD9VV3gbLdacQBnYSUE5VL5Q
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable
 
 On 03.08.2018 15:02, Kamil Rytarowski wrote:
 > On 03.08.2018 09:07, matthew green wrote:
 >>>  This is not a bug. It works as intended.
 >>> =20
 >>>  NetBSD behavior is compliant with POSIX and 3rd party program has to=
  be
 >>>  fixed and handle the -1 case on its own, if there is need to disting=
 uish
 >>>  error and unsupported, there is an option to reset errno and check i=
 t
 >>>  after the call.
 >>
 >> this makes no sense to me.  opengroup says:
 >>
 >>    If unsuccessful, they shall return a value of -1 and set errno
 >>    to indicate the error.
 >>
 >> so "-1" can not be a useful value by definition.  clearly our
 >> implementation needs to map between internal values and ones
 >> we return to these functions if "-1" is interanlly useful.
 >>
 >> it's also extremely awful to introduce more APIs that abuse errno
 >> like you suggest, and should not be done any time.
 >>
 >>
 >> .mrg.
 >>
 >=20
 > I'm referring to a line documented from different pages:
 >=20
 > If the current scheduling policy for the target process is not
 > SCHED_FIFO, SCHED_RR, [SS] [Option Start] or SCHED_SPORADIC, [Option
 > End]  the result is implementation-defined; this case includes the
 > SCHED_OTHER policy.
 >=20
 > http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_setpara=
 m.html#
 >=20
 > For SCHED_OTHER, the affected scheduling parameters are
 > implementation-defined.
 >=20
 > http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setsc=
 hedparam.html
 >=20
 > And some other places with similar wording.
 >=20
 > Additionally:
 >=20
 >=20
 > 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.
 >=20
 > http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.htm=
 l#tag_15_08_04_05
 >=20
 > -1 indicated that no priority policy (or PRI_NONE one as an
 > implementation specific type of NetBSD) can be used with SCHED_OTHER.
 >=20
 > PRI_NONE is not technically an error, so not errno set - but the result=
 
 > is the same as it cannot be changed.
 >=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).
 
 
 --eovONmXsGAD9VV3gbLdacQBnYSUE5VL5Q--
 
 --ibdZQT2m5JkcugrGH6aF6tg5Bct1G1Otc
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 
 iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAltkVjAMHG41NEBnbXgu
 Y29tAAoJEEuzCOmwLnZsUHsP/R9twHCEXoiMxHE05kJ3v5LqT7LcsGPqtoGJe6DI
 AZZDqfp59CAeyHJ7xQFopA2n87qViuPoEfGGXruNVqHD8H3Hsv49pQ7r2D1usuMB
 t/6uCZMTwIPIu5/zTZ8ikbiBTdgTLHLvCQW67SjYcL8qnBN9F6+BQABV/9SM2dpm
 yoJV1nPC67KjQnf3W6UF6LzcoRQAaIcnAzaW5VunOTeVo5UtRbO25A9Z6ZovywtP
 +50VQOa7PJ0pS0Jl1q35NljD1WLFSVYyNjLLAm35P++9fReIec1NX1Fdl/qY1RUA
 mj1pqcLvPN+XRH4aBa306dHu0LFsCl+bYNUZG/TxgZOSwoSRWWOYnm7T0UdrIgO4
 Sm/q2VeFuPrHPSvXOHOwFlce8bV1ib/0CkxlGudJXZtnR06M8LLaMWCLgQUdciEL
 5yABxx+JmyXqq2/dYFBwcTZfS4OEF7+ZKkqniaCxnJrKFOHvK3W0ux3IE8H0Ny5W
 Ir74PyUR1/P77tfyLfFD9tmdjBCptjhQYd0S1MtMOLeBwJN2G8LR9NDqT0+fFHAb
 XeVBfuwRQFNqKXZKsUKDF/Z89L1blvuk69bjzX5vYk6zEmZfsvAL113Gd1lEUq5P
 DtDtTX2NGXYP0wTkq9c7jE1PgLK3tjVxs7REb98Unbm+++TtRFM/5Igcw/YWpOnL
 ZtQK
 =EAQc
 -----END PGP SIGNATURE-----
 
 --ibdZQT2m5JkcugrGH6aF6tg5Bct1G1Otc--