Horizon (Nintendo 3DS) pthread functions and non-portable extensions #2715
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The pthread_attr_t type can have priority and affinity values set. pthread_getpriority returns the priority of the current thread. These are needed to enable std thread support. std can't link directly with libctru so we go through pthread as an intermediate interface.
Also adds a get version, to keep consistency.
I chose the scheduler priorities based on https://man7.org/linux/man-pages/man7/sched.7.html I think the cooperative app cores are most like SCHED_FIFO, while the sys core is similar to SCHED_RR. However, I don't think our pthread implementation would be able to accurately return the right policy since we need to know what processor the thread is running on, and the only API to get that gets the ID for the current thread. Since the pthread function passes in a thread ID, we are unable to always get the processor ID and thus the policy. In this case, I think we should just always return (and accept in set) SCHED_FIFO. I don't think this will be used anyways.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) soon. Please see the contribution instructions for more information. |
|
LGTM! @bors r+ |
|
📌 Commit b62064b has been approved by |
|
☀️ Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds some standard and nonstandard pthread/threading functions to the horizon (Nintendo 3DS) operating system. This will allow us to open a PR to std for std threads support.
The Nintendo 3DS doesn't have a full libc implementation, so there are some user libraries which implement part of libc, such as libctru:
https://github.com/devkitPro/libctru
For some more context on this situation, see rust-random/getrandom#248
But std doesn't want to interface directly with anything that could be seen as using the "internal" interfaces of the 3DS or consoles in general:
rust-lang/rust#88529 (comment)
So we work around this by implementing standard pthread interfaces, plus some nonstandard ones as necessary, and expose that interface to std:
https://github.com/Meziu/pthread-3ds
Here's the justifications for the nonstandard interfaces:
pthread_attr_setprocessorid_np(and thegetversion):The 3DS requires the core a thread runs on to be specified at thread creation time. I'm pretty sure you can't migrate threads across cores. Additionally, the cores act differently (ex. one core is cooperatively scheduled). This means we need to have an API to set the core to use in the thread attributes struct. We didn't find any relevant standard API for this, so we added a nonstandard one.
pthread_getprocessorid_np:The 3DS lets you get the core/processor ID of the executing thread. But it doesn't have a function to get the core ID of any arbitrary thread. We didn't find any standard APIs which would match these semantics, so we added a nonportable one. One place this API is used is to get the default core/processor ID when spawning a thread (i.e. spawn the thread on the current processor).
For more context, see:
cc: @ian-h-chamberlain @Meziu