macOS support #9
Conversation
| //! use thread_priority::*; | ||
| //! | ||
| //! assert!(set_current_thread_priority(ThreadPriority::Min).is_ok()); | ||
| //! let result = set_current_thread_priority(ThreadPriority::Min); |
There was a problem hiding this comment.
Can I ask why did you remove the assertion? This was an example and a doc-test which was running and which was testing the library...
There was a problem hiding this comment.
On macOS it blows an error because the implementation there is a stub
There was a problem hiding this comment.
This is the pattern which works in my application. "optional" thread priority change.
// Ignore the response- we just keep going even if priorty can not be boosted on a given platform
let _ = thread_priority::set_current_thread_priority(thread_priority::ThreadPriority::Max);
So you can pay attention to whether it is implemented for the current OS, but as an app developer you don't have to.
|
Let it be failing then :) I'll implement the macos part this week.
…On Mon, 23 Mar 2020 at 19:18, Paul Houghton ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/lib.rs
<#9 (comment)>:
> @@ -7,21 +7,25 @@
//! ```rust
//! use thread_priority::*;
//!
-//! assert!(set_current_thread_priority(ThreadPriority::Min).is_ok());
+//! let result = set_current_thread_priority(ThreadPriority::Min);
On macOS it blows an error because the implementation there is a stub
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIX4AIIXTVDRMU2MWQUZMTRI6RVNANCNFSM4LSBLIAQ>
.
--
Best, Victor Polevoy.
|
|
Excellent |
|
Any progress on this front, while not required for my use case, it would be very nice for this to also work on mac. |
|
Hi @cwfitzgerald, Unfortunately, not much progress. I did some a while ago (after my last post here), but have never committed the changes and pushed. Haven't really had enough time between my projects to finally do something about it. Should you wish to work on it yourself, you are always welcome, but from my side I can't really tell when this can happen. If there were a simple and known solution to that, I'd finish it within a day, but the macOS's posix compatibility is not straightforward, and they are using cocoa to manage threads, so this required (and still requires as I have already forgotten my previous research results again) an investigation into the macOS thread management (and the best way to implement it here). |
|
I am trying to add the same support as we have for Linux for macOS. Check this out: #16 |
|
Closing this in favour of #16 |
3 participants
Recent changes are tested in Windows. No apparently problems. Excellent!
This PR add a stub for macOS to eliminate the need for runtime platform checks. Instead a specific new exception type is thrown for UnsupportedPlatform while still allowing compilation despite C stdlib differences from Unix standard.
I've assumed that macOS is the exception to platform family "unix". An alternative would be that "linux" is the only platform supporting our threading constructs- not sure, but a reasonable guess which works either way.
Some of the documentation examples needed simplification to avoid "docs are always on Linux, so the old example assertions in docs were not true due to UnsupportedPlatform" when running tests on mac. Thus you likely want to bump the secondary version number for any release.