bpo-41839: Fix error checking in sched_get_priority_ functions

[kulikjak]

Python presumes that any negative number returned from sched_get_priority_min or sched_get_priority_max indicates that error has occurred. However, neither Linux manual pages nor POSIX.1-2001 specification forbids negative values to be returned; only -1 has a special meaning for error.

https://bugs.python.org/issue41839

[kulikjak]

If this seems too dangerous to merge to you, we can use the variant used by OmniOS instead, which is not as nice & simple, but definitely won't break existing stuff.

https://github.com/citrus-it/omnios-build/blob/python39/build/python39/patches/mod-posix-sched_priority.patch

[jstasiak]

Is it guaranteed that a successul syscall clears errno? Because if yes, then the if (max == -1) will still report legitimate -1 priority as an error. The illumos man page says "If unsuccessful, they return -1 and set errno to indicate the error." and I may be reading too much into this, but if errno is not set to indicate an error is a sufficient condition to conclude there's no error I think?

[kulikjak]

It is not guaranteed, and this simple case confirms that it is not being cleared:

errno = EINVAL;
res = sched_get_priority_min(SCHED_OTHER);
printf("%d %d\n", res, errno);  // EINVAL is still set

but we can still do it ourselves.

You are right that -1 is still a legitimate priority, and although I don't think it even happens in any Solaris (historically, some schedulers used -60 and 60, the newer ones are using positive values only), it is not impossible (and also, I might be wrong :)).

I updated the code, now it should always work on systems where sched_get_priority_* is POSIX.1-2001 compliant (which is True for Linux as well as all Unix systems) no matter the priority.

[mtelka]

What needs to be done to see this PR merged? The change is obviously improving compatibility with POSIX and there is not known any regression.

Thank you.