Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add sched_getscheduler & sched_setscheduler #1195

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ruihe774
Copy link

Solve #1183

@ruihe774 ruihe774 force-pushed the scheduler branch 11 times, most recently from fe41569 to abf9ee5 Compare October 23, 2024 10:52
Copy link
Member

@sunfishcode sunfishcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you say more about the use case that motivates this PR? In #1183, the reporter actually needed pthread_setschedparam etc., which has more consistent behavior across platforms, which isn't entirely unimplmented on musl, and which cooperates with the platform libpthread rather than working behind its back, so it's better for most users.

Rustix may still want to add sched_setscheduler, but I'd like to understand how it would be used so that we can write a documentation comment pointing people to pthread_setschedparam in situations where that would be better.

src/backend/linux_raw/process/types.rs Show resolved Hide resolved
@ruihe774
Copy link
Author

Could you say more about the use case that motivates this PR? In #1183, the reporter actually needed pthread_setschedparam etc., which has more consistent behavior across platforms, which isn't entirely unimplmented on musl, and which cooperates with the platform libpthread rather than working behind its back, so it's better for most users.

Rustix may still want to add sched_setscheduler, but I'd like to understand how it would be used so that we can write a documentation comment pointing people to pthread_setschedparam in situations where that would be better.

I don't think so. sched_setscheduler is also in POSIX standard. And pthread_setschedparam does not have more consistent behavior across platforms; its arguments policy and sched_param are the same as sched_setscheduler and still vary across platforms. I don't think there is much difference between these two APIs.

And using pthread_setschedparam means we cannot implement it in linux_raw and requires the libc.

In Linux, scheduling is not managed by libpthread; pthread_setschedparam is just a slim wrapper to sched_setscheduler. So there is no such thing that "cooperates with the platform libpthread rather than working behind its back". For other platforms, we use libc anyway.

@sunfishcode
Copy link
Member

Could you say more about the use case that motivates this PR? In #1183, the reporter actually needed pthread_setschedparam etc., which has more consistent behavior across platforms, which isn't entirely unimplmented on musl, and which cooperates with the platform libpthread rather than working behind its back, so it's better for most users.
Rustix may still want to add sched_setscheduler, but I'd like to understand how it would be used so that we can write a documentation comment pointing people to pthread_setschedparam in situations where that would be better.

I don't think so. sched_setscheduler is also in POSIX standard. And pthread_setschedparam does not have more consistent behavior across platforms; its arguments policy and sched_param are the same as sched_setscheduler and still vary across platforms. I don't think there is much difference between these two APIs.

sched_setscheduler isn't portable between glibc and musl.

It appears that all of linux/glibc, linux/musl, FreeBSD, and POSIX all support pthread_setschedparam.

And using pthread_setschedparam means we cannot implement it in linux_raw and requires the libc.

Could you say more about your use case?

In Linux, scheduling is not managed by libpthread; pthread_setschedparam is just a slim wrapper to sched_setscheduler. So there is no such thing that "cooperates with the platform libpthread rather than working behind its back". For other platforms, we use libc anyway.

glibc's wrapper does do some additional things, including update some metadata that would become stale if the user used sched_setschedparam directly. I don't know how hazardous that is, but it looks subtle enough that it'd be good to give users guidance.

@ruihe774
Copy link
Author

sched_setscheduler isn't portable between glibc and musl.

We can implement it using raw syscall if musl does not provide it.

Could you say more about your use case?

I consider not "requires the libc" an advantage.

I don't know how hazardous that is, but it looks subtle enough that it'd be good to give users guidance.

Right.

I can implement both and point that in doc.

@ruihe774
Copy link
Author

I can implement both

The problem is that pthread_setschedparam and pthread_getschedparam take pthread_t, which is not available in rustix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants