-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
panic when encountering an illegal cpumask in thread::available_parallelism #115946
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
@bors r+ rollup |
This function can error, and one of the error is
Is it better to return an error of this kind and let user to decide whether to panic or not, instead of always panicing? |
This only happens when the system API violates its own API contract. That is different from the system API not being available or returning an explicit error. And as commented on the code and in the associated issue this is only known to happen on an outdated kernel below our minimum supported version.... which means we don't need to support that. |
I understand where you are coming from. I do however feel a bit of unease when something that is essentially a "get" function panics. It would be pretty trivial to recover from such error from a user point of view, e.g. just |
Since the method already returns a |
…llaumeGomez Rollup of 6 pull requests Successful merges: - rust-lang#112725 (rustdoc-search: add support for type parameters) - rust-lang#114941 (Don't resolve generic impls that may be shadowed by dyn built-in impls) - rust-lang#115625 (Explain HRTB + infer limitations of old solver) - rust-lang#115839 (Bump libc to 0.2.148) - rust-lang#115924 (Don't complain on a single non-exhaustive 1-ZST) - rust-lang#115946 (panic when encountering an illegal cpumask in thread::available_parallelism) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#115946 - the8472:panic-on-sched_getaffinity-bug, r=Mark-Simulacrum panic when encountering an illegal cpumask in thread::available_parallelism Fixes rust-lang#115868 by panicking instead of returning an invalid `NonZeroUsize`
…-bug, r=cuviper Fall back to _SC_NPROCESSORS_ONLN if sched_getaffinity returns an empty mask Followup to rust-lang#115946 A gentler fix for rust-lang#115868, one that doesn't panic, [suggested on zulip](https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/Meeting.202023-09-19/near/391942927) In that situation - on the buggy kernel versions - a zero-mask means no affinities have been set so `_SC_NPROCESSORS_ONLN` provides the right value.
Rollup merge of rust-lang#116038 - the8472:panic-on-sched_getaffinity-bug, r=cuviper Fall back to _SC_NPROCESSORS_ONLN if sched_getaffinity returns an empty mask Followup to rust-lang#115946 A gentler fix for rust-lang#115868, one that doesn't panic, [suggested on zulip](https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/Meeting.202023-09-19/near/391942927) In that situation - on the buggy kernel versions - a zero-mask means no affinities have been set so `_SC_NPROCESSORS_ONLN` provides the right value.
Fixes #115868 by panicking instead of returning an invalid
NonZeroUsize