Ideas for improvement

[hellow554]

This thread is just a bunch of ideas flying around in my head, so feel free to either close this issue or comment on it. I'm fine with both ;)

---

Make a ThreadExt trait and implement the function set_priority and other with respect to the OS for std::thread::Thread.
This would make things seamless, e.g.

std::thread::current().set_thread_priority_and_policy(...)

You could also extend std::thread::Builder and have a function priority where you specify the priority beforehand.

---

Unify common functions.

What I mean by that is that currently I have to take a look into the unix mod to see what functions are available to me. This makes sense because unix might offer different things that windows does. But I would like to have a common struct/trait that combine the lowest common denominator. You can then do something sililar to what the std does by having a OS specific trait that extends your struct.
For an example what I mean look at std::fs::File with the AsRawFd and AsRawHandle traits.

---

Restrict the creation of invalid states.
I see that the ThreadPolicy enum can have an invalid state where when you pass a value beyond 100 to the Specific variant (btw. the documentation there says [0; 100] (read including 0 and 100), but the code says [0; 100) (read including 0, excluding 100). There needs to be a correction.

One way of doing this might be that the variant Specific does not hold a u32, but a struct SpecificNumber that has a new function which restricts the value passed to it and returning a Result.
Second would be that ThreadPolicy is a struct containing a single, non-public, enum. Similar to this: https://stackoverflow.com/questions/28090120/can-i-create-private-enum-constructors.

This way you can have some functions not returning a Result anymore, because they can't fail.

---

Create a few examples in the repo.
People love examples and hate reading docs (although I love reading rust docs, because they are unified and so pleasent to read). But a dedicated examples folder with just one example would spice things up and let people investigate everything they can do with this crate without looking into every function available.

Let me know what you think about this.
This crate looks nice and it perfectly fits into my current project. So thank you for developing it :)

[iddm]

I really appreciate your suggestions and will do them one by one! :-)

[iddm]

This thread is just a bunch of ideas flying around in my head, so feel free to either close this issue or comment on it. I'm fine with both ;)

Make a ThreadExt trait and implement the function set_priority and other with respect to the OS for std::thread::Thread.
This would make things seamless, e.g.

std::thread::current().set_thread_priority_and_policy(...)

This part is a nice-to-have thing, but impossible to implement. There is no way to map the std::thread::Thread::id to thread_priority::ThreadId - simply the Rust's thread id is an internal thing only known to rust and exposed for god-knows-which purposes (it is even useful to have?). Had there been a way to get the native thread id from Rust's thread id, there would have been a way to do this. The functions I can implement in such a trait are only for the current calling thread, but the Thread struct isn't just for the current thread but for all threads in rust, hence such an implementation isn't useful. For example, right now (uncommitted) I have this implemented:

/// A helper trait for other threads to implement to be able to call methods
/// on threads themselves.
pub trait ThreadExt {
    /// Sets the current thread's priority.
    /// For more info see [`ThreadPriority::set_for_current`].
    fn set_priority(&self, priority: ThreadPriority) -> Result<(), Error> {
        priority.set_for_current()
    }
}

As you can see, it is only useful when we need to set priority on the current calling thread. It is impossible to get what native thread it is in Rust without any additional knowledge, besides, even this is unstable (the implementation details may change at any time). So I decided just not to implement it, as there are already functions for doing this in the crate.

You could also extend std::thread::Builder and have a function priority where you specify the priority beforehand.

This is, unfortunately, also impossible. The Builder has to store the priority passed somewhere so that during the build() call it can do all the magic, like naming a thread, setting stack size and etc, and it is impossible to extend this structure. Besides, after that, I can't hook up on any callback to set the priority. And the last thing, even if all mentioned had been possible, it would have been impossible due to the thing I mentioned in the previous answer - there is no way to map the Rust's thread id to a native thread id, hence no way to do anything useful.

Without a proper Rust's exposure of thread details in any possible way, it is impossible to integrate with it. If you really want to have all of this done, there should be a separate crate then for all the threading stuff, duplicating the std::thread crate's functionality but including the priority settings. This is unfortunate to hear, I know, but this is how the things are.

I continue looking at the other things you mentioned.

[iddm]

This thread is just a bunch of ideas flying around in my head, so feel free to either close this issue or comment on it. I'm fine with both ;)

Make a ThreadExt trait and implement the function set_priority and other with respect to the OS for std::thread::Thread. This would make things seamless, e.g.

std::thread::current().set_thread_priority_and_policy(...)

You could also extend std::thread::Builder and have a function priority where you specify the priority beforehand.

Unify common functions.

What I mean by that is that currently I have to take a look into the unix mod to see what functions are available to me. This makes sense because unix might offer different things that windows does. But I would like to have a common struct/trait that combine the lowest common denominator. You can then do something sililar to what the std does by having a OS specific trait that extends your struct. For an example what I mean look at std::fs::File with the AsRawFd and AsRawHandle traits.

Restrict the creation of invalid states. I see that the ThreadPolicy enum can have an invalid state where when you pass a value beyond 100 to the Specific variant (btw. the documentation there says [0; 100] (read including 0 and 100), but the code says [0; 100) (read including 0, excluding 100). There needs to be a correction.

One way of doing this might be that the variant Specific does not hold a u32, but a struct SpecificNumber that has a new function which restricts the value passed to it and returning a Result. Second would be that ThreadPolicy is a struct containing a single, non-public, enum. Similar to this: https://stackoverflow.com/questions/28090120/can-i-create-private-enum-constructors.

This way you can have some functions not returning a Result anymore, because they can't fail.

Create a few examples in the repo. People love examples and hate reading docs (although I love reading rust docs, because they are unified and so pleasent to read). But a dedicated examples folder with just one example would spice things up and let people investigate everything they can do with this crate without looking into every function available.

Let me know what you think about this. This crate looks nice and it perfectly fits into my current project. So thank you for developing it :)

How do you like the #14 ?

[iddm]

@hellow554 If you think your proposal is fully addressed in #14 , can you please close the issue?
UPD: It is live now. You may check out the new changes and test them, or just look at the docs there, hopefully, they are better now a bit :)