Support multiple platforms roadmap

[iddm]

• linux thread priority
• osx thread priority
• bsd thread priority
• windows thread priority
• ios?

[iddm]

For windows threads, we could use this: https://docs.rs/winapi/0.3.8/x86_64-pc-windows-msvc/winapi/um/processthreadsapi/fn.SetThreadPriority.html either by linking ourselves or through the winapi crate.

[iddm]

For the OSX, there is currently no easy way to do right now: the libc crate doesn't allow using POSIX threads on macOS, all the CoreFoundation bindings don't allow working with NSThread out-of-the-box.

[paulirotta]

A useful first step would be to shift into platform-specific modules. Here is an example from the application level which might be adapted into the library.

Would you like a pull request to shift the current API into modules according to this pattern?

Is it preferred to do nothing on unsupported platform, or treat that as an Option<> in a return value?

#[cfg(target_os = "linux")]
mod max_thread_priority {
    pub fn maximize_current_thread_priority() {
        let thread_id = thread_priority::thread_native_id();
        let _ = thread_priority::set_thread_priority(
            thread_id,
            thread_priority::ThreadPriority::Max,
            thread_priority::ThreadSchedulePolicy::Normal(
                thread_priority::NormalThreadSchedulePolicy::Normal,
            ),
        )
        .expect("Could not maximize thread priority");
    }
}

#[cfg(not(target_os = "linux"))]
mod max_thread_priority {
    pub fn maximize_current_thread_priority() {
        // Do nothing- thread priority override is not currently supported on this platform
    }
}

[iddm]

Hi there! Thank you for your help! I have been already doing that for some time. It just wasn't my #1 priority, so that I have not committed anything yet. No one has contacted me about other oses support and it is quite difficult to know whether people really need it or not, and so, whether to invest your time into this or not (even if you are not obliged to).

[paulirotta]

Hi Victor!
The Internet community.. just is. 😁
I'm appreciating the library and would use cross-platform gladly. It helps responsiveness on low end hardware especially in my case or when you push closer to the limits.

If you push when ready I can look at adding or at least starting Windows. Time is always precious but we benefit so much from open source. Don't loose the faith, brother.

[iddm]

@paulirotta I've pushed my changes there. Feel free to check out, review, contribute. I don't think I will have time to develop the windows part soon. What I want from this crate is to remain as simple as possible: provide the simplest possible way to manage priorities and scheduling policies. Nothing else, nothing less, just that. I'd also like to not using the winapi crate and as minimum crates as possible because this crate (thread-priority) may be used as a very top in the hierarchy and this may cause compatibility issues. But, eventually, I gave up and allowed myself to use the winapi. So, if you want to contribute or develop the windows part, you are welcome, but keep in mind my position or try arguing with it :) I may implement the windows part myself, just not sure when exactly. So don't count on me :(

P.S. The functions to use, I guess, are these: GetThreadId for thread_native_id function, GetThreadPriority and SetThreadPriority for managing the priority using ThreadPriority enum and set_* functions. Also, the travis configuration file should have a windows node added.

[iddm]

Just added a few lines of code for Windows in the windows branch. Haven't even tried building the code yet, as I don't quite have windows at this moment ;) Also, the code there lacks using of threading policies in windows. We should add those there, to be feature-compliant with Linux.

[iddm]

Actually, I think, you may already try out the branch yourself and check if it works for you. Because I am already using the functions in the tests, and so if the tests don't fail in travis, they shouldn't fail on a real system.

[iddm]

I've merged the branch, tests seem to be passing, feel free to file a bug or contribute in any other way. Hope this helps and works for you.

[paulirotta]

Thanks! I'll start working against that, report my findings and look for time to help on the Windows port or other suggestions. I've had good results with the earlier release version on PC/Mint and Jetson Nano/Ubuntu. Windows will be the main target in coming weeks.

[dljsjr]

Hey there, I found your crate a few months back and have been using it with some success! Stumbled on to this tracking issue though and wanted to mention that the current *nix bindings only work on GCC libc but not when using a musl based target. I think it's probably as straight forward as swapping out some system calls, but the short version is that (from my understanding) some of the stuff exposed by the low-latency/fully preemptible kernel patches is not POSIX compliant but can be implemented in other ways and musl doesn't let you do the non-POSIX-compliant versions. An example of that can be found here: https://www.openwall.com/lists/musl/2016/03/01/5

This might not be solvable in this crate, it might be something in the libc crate, but just wanted to chime in!

[dljsjr]

For the OSX, there is currently no easy way to do right now: the libc crate doesn't allow using POSIX threads on macOS, all the CoreFoundation bindings don't allow working with NSThread out-of-the-box.

You can actually configure the real-time priority of pthreads on macOS w/out needing NSThread or CoreFoundation but it's done via the Mach ports API

I should make note that it's been a LONG time since I used those APIs for real-time threading on macOS and they may no longer be available w/ the new security stuff that Apple has been rolling out over time.

[iddm]

Hey there, I found your crate a few months back and have been using it with some success! Stumbled on to this tracking issue though and wanted to mention that the current *nix bindings only work on GCC libc but not when using a musl based target. I think it's probably as straight forward as swapping out some system calls, but the short version is that (from my understanding) some of the stuff exposed by the low-latency/fully preemptible kernel patches is not POSIX compliant but can be implemented in other ways and musl doesn't let you do the non-POSIX-compliant versions. An example of that can be found here: https://www.openwall.com/lists/musl/2016/03/01/5

This might not be solvable in this crate, it might be something in the libc crate, but just wanted to chime in!

Hello and welcome! Thanks for your report, and yes, I have not ever been thinking of a possible linking with musl :) IIRC the libc crate has some conditional compilation if used with musl, so it might be that we may look into the libc crate, agreed.
I might have a look in a few weeks from now, so if you have a strong will for help, feel free to do that earlier, I will appreciate :)
Besides, I have already put some changes in the libc crate in order to make this one possible to implement :) So it won't be new to me. It was a really simple change, you may start looking from there if you wish to.