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 rust3ds/ctru-rs#97 (comment)

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: Expose thread/task priorities rust-lang/rfcs#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: std::thread support for the Nintendo 3DS rust-lang/rust#98514
• and a proposal for a new Builder API, which has had some discussion back and forth Add Special Thread Builder Functions for the Nintendo 3DS rust-lang/libs-team#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 Partially implement thread scheduling attributes API proposal rust-lang/rust#101222 but I wasn't totally convinced it was the right option overall.

At this point, this is my rough plan:

1. 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. 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. Submit the proposal, try to get some final feedback, and implement it.
4. 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 rust-lang/libs-team#195 ! @AzureMarker not sure if you want to close rust-lang/libs-team#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