Thread priority + affinity

[ian-h-chamberlain]

Regarding the unsupported functionality, I'm still of the opinion that getting any kind of threading support would be necessary, as it doesn't really seem fair to release ctru-rswith halfbaked dev-only features, like std-threads.

Originally posted by @Meziu in https://github.com/rust3ds/ctru-rs/discussions/97#discussioncomment-5295698

I wasn't sure where else to make an issue but I thought this repo seemed sort of sensible to track progress on the upstream threads proposal and related changes.

It will probably take a little while, but I plan to revisit the original thread proposal with the Rust team and see if we can come to some kind of middle ground that doesn't result in implementing a huge API surface in std just to support our platform.

As a brief summary of what's happened:

• Since long ago, thread priority has been requested in std: https://github.com/rust-lang/rfcs/issues/819
• There are some third party crates for this, which maybe we should consider looking into (perhaps that is enough for our use case if we can make it work?
  • https://github.com/vityafx/thread-priority
  • https://github.com/Elzair/core_affinity_rs
• @AzureMarker opened a PR to enable full blown threads in std: https://github.com/rust-lang/rust/pull/98514
• and a proposal for a new Builder API, which has had some discussion back and forth https://github.com/rust-lang/libs-team/issues/71
• We also had some discussion on Zulip about the proposal, which has kind of gone back and forth
• I took a stab at implementing the proposal in https://github.com/rust-lang/rust/pull/101222 but I wasn't totally convinced it was the right option overall.

At this point, this is my rough plan:

1. [x] Do more research on the affinity and priority crates I mentioned above. If it's not hard to add the support we are looking for via those, maybe we can delay the std changes and just rely on them instead
2. [x] If std still seems like a better option, rewrite the API proposal to be more generic (less 3DS-focused) and address some of the discussion concerns that have come up. I will probably end up mentioning the above crates as prior art in this space too.
3. [x] Submit the proposal, try to get some final feedback, and implement it.
4. [x] Add necessary libc APIs to implement new affinity APIs for std
5. [ ] Assuming all the above goes well, adjust ctru-rs examples and features to match the new std API.

Phew! This has been a long time coming so hopefully we can finally put it to rest somewhere. Also let me know if you think this issue makes more sense to live on ctru-rs and I can transfer, it's kind of broad so I wasn't sure the best place to put it.

[Meziu]

Hmm, the presence of those third-party crates is interesting. Unless Rust's lib-team let's us add a system specific module, I don't know if we can really depend on a system-agnostic implementation (that would be the main goal of a std PR). Maybe we should try to pass the functionality to third party crates in the form of pthread-3ds functions and depend on those (at least for now).

The problem is that we can't really depend on some stranger's code for long. At this point I wonder, should we really discard the idea of including that functionality directly in ctru-rs? It's a very complex issue...

[ian-h-chamberlain]

Ok, I just opened https://github.com/rust-lang/libs-team/issues/195 ! @AzureMarker not sure if you want to close https://github.com/rust-lang/libs-team/issues/71 since I think this proposal would probably make it unnecessary.

Feel free to take a look / comment, hopefully we can get some feedback from libs team and try to move this along!

~Meanwhile I think I will try to add some more scheduling APIs to libc since we're probably gonna need them one way or another.~ nvm, I forgot the names are different, linux has pthread_attr_setprocessorid_np but we have pthread_attr_setprocessorid_np instead. I can implement it in terms of that