Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

bpo-41839: Fix error checking in sched_get_priority_ functions#22374

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
kulikjak wants to merge8 commits intopython:main
base:main
Choose a base branch
Loading
fromkulikjak:fix-sched-error-checking

Conversation

kulikjak
Copy link
Contributor

@kulikjakkulikjak commentedSep 23, 2020
edited
Loading

Python presumes that any negative number returned fromsched_get_priority_min orsched_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

mtelka reacted with thumbs up emoji
@kulikjak
Copy link
ContributorAuthor

kulikjak commentedNov 2, 2020
edited
Loading

If this seems too dangerous to merge, we can use the variant used by OmniOS instead, which makes the change Solaris specific.

https://github.com/omniosorg/omnios-build/blob/master/build/python313/patches/mod-posix-sched_priority.patch

@jstasiak
Copy link
Contributor

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
Copy link
ContributorAuthor

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 wheresched_get_priority_* is POSIX.1-2001 compliant (which is True for Linux as well as all Unix systems) no matter the priority.

@kulikjakkulikjakforce-pushed thefix-sched-error-checking branch 2 times, most recently fromfe9ee56 tod1a27a6CompareAugust 23, 2022 12:02
@kulikjakkulikjakforce-pushed thefix-sched-error-checking branch from5b7ab02 to4d818a2CompareMarch 20, 2023 13:42
kulikjak added a commit to kulikjak/cpython that referenced this pull requestMar 20, 2023
kulikjak added a commit to kulikjak/cpython that referenced this pull requestMay 9, 2023
@kulikjakkulikjakforce-pushed thefix-sched-error-checking branch from4d818a2 tof55a532CompareNovember 7, 2023 09:59
@mtelka
Copy link

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.

kulikjak reacted with thumbs up emoji

kulikjakand others added2 commitsJuly 14, 2025 13:11
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@serhiy-storchakaserhiy-storchakaserhiy-storchaka left review comments

@jstasiakjstasiakjstasiak approved these changes

@ZackerySpytzZackerySpytzZackerySpytz approved these changes

Assignees
No one assigned
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

8 participants
@kulikjak@jstasiak@mtelka@serhiy-storchaka@ZackerySpytz@the-knights-who-say-ni@ezio-melotti@bedevere-bot

[8]ページ先頭

©2009-2025 Movatter.jp