Skip to content

Can we avoid the heap allocation in macOS Mutex/Condvar? #131005

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
RalfJung opened this issue Sep 29, 2024 · 1 comment
Open

Can we avoid the heap allocation in macOS Mutex/Condvar? #131005

RalfJung opened this issue Sep 29, 2024 · 1 comment
Labels
A-atomic Area: Atomics, barriers, and sync primitives C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such O-macos Operating system: macOS T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@RalfJung
Copy link
Member

This was brought up over here: our current macOS implementation for Mutex and Condvar use heap allocations. That's unfortunate because it can lead to OOM, and also seems like a slight efficiency hit.

Heap allocations are required because we are using the pthread API on macOS, and pthread Mutexes are not movable. AFAIK, @joboet has been working on alternative implementations that avoid the pthread API (#122408). The alternative, suggested by @daira , is to get Apple to guarantee that their pthread mutexes are movable under certain conditions. Given the black box that Apple is, I have no idea if that's even remotely realistic. But anyway it seems worth tracking this somewhere so here we go. :)

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Sep 29, 2024
@lolbinarycat lolbinarycat added O-macos Operating system: macOS A-atomic Area: Atomics, barriers, and sync primitives labels Oct 2, 2024
@joboet
Copy link
Member

joboet commented Oct 10, 2024

Given the black box that Apple is, I have no idea if that's even remotely realistic.

Not at all realistic. I can't even get Apple to respond to bug reports, let alone feature suggestions.

@Noratrieb Noratrieb added T-libs Relevant to the library team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Nov 9, 2024
@workingjubilee workingjubilee added the C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such label Feb 14, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-atomic Area: Atomics, barriers, and sync primitives C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such O-macos Operating system: macOS T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants