Skip to content
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

std::unix::thread fix available_parallelism on netbsd/32 bits. #126162

Conversation

devnexen
Copy link
Contributor

@devnexen devnexen commented Jun 8, 2024

when bootstrapping rust, it segfaults in i386, ppc, arm ... there is no cpu attached by default in such early stage.
therefore removing the affinity api and falls back on the always reliable sysctl/HW_NCPU call instead.

when bootstrapping rust, it segfaults in i386, ppc, arm ... there is
no cpu attached by default in such early stage.
therefore removing the affinity api and falls back on the always reliable
sysctl/HW_NCPU call instead.
@rustbot
Copy link
Collaborator

rustbot commented Jun 8, 2024

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 8, 2024
@Amanieu
Copy link
Member

Amanieu commented Jun 8, 2024

Can you explain why this would segfault? Can't we just fall back if pthread_getaffinity_np returns an empty set?

@devnexen
Copy link
Contributor Author

devnexen commented Jun 8, 2024

it segfaults at

match libc::_cpuset_isset(i, set)

which might indicate a system issue if pthread_getaffinity_np returns success ... but it does crash on 32 bits.
so for simplicity sake, instead of enabling it only on 64 bits, I propose to remove wdyt ?

@Amanieu
Copy link
Member

Amanieu commented Jun 10, 2024

I would prefer if this was fixed to work properly, but I can also accept just removing it.

@Amanieu Amanieu added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 23, 2024
@Amanieu
Copy link
Member

Amanieu commented Jul 23, 2024

Could you debug the issue on netbsd to figure out why it is crashing? We are using the C API correctly as far as I can tell. Maybe the libc bindings are incorrect?

@JohnCSimon
Copy link
Member

@devnexen
ping from triage - can you post your status on this PR? This PR has not received an update in a few months.

@devnexen
Copy link
Contributor Author

devnexen commented Sep 4, 2024

Apologies I got sidetracked in the meantime. After updating the platforms, I could no longer reproduce.

@devnexen devnexen closed this Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-unix Operating system: Unix-like S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants