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

Shim the macOS futex API #3962

Open
joboet opened this issue Oct 10, 2024 · 5 comments
Open

Shim the macOS futex API #3962

joboet opened this issue Oct 10, 2024 · 5 comments
Labels
A-concurrency Area: affects our concurrency (multi-thread) support A-mac Area: Affects only macOS targets A-shims Area: This affects the external function shims C-enhancement Category: a PR with an enhancement or an issue tracking an accepted enhancement

Comments

@joboet
Copy link
Member

joboet commented Oct 10, 2024

Since macOS 14.4, the Apple platforms have a public futex-like interface, which we'd very much like to use in std (see rust-lang/rust#122408), but we're still missing the miri shims for it. In typical Apple fashion, they have failed to upload the full documentation to their website and have not included it in their man-pages either. Still, it exists and can be accessed either from the header file (os/os_sync_wait_on_address.h) or from its upload to their public-source repository.

@RalfJung
Copy link
Member

Is this the same as / a replacement of #2589?

@RalfJung RalfJung added C-enhancement Category: a PR with an enhancement or an issue tracking an accepted enhancement A-shims Area: This affects the external function shims A-mac Area: Affects only macOS targets A-concurrency Area: affects our concurrency (multi-thread) support labels Oct 10, 2024
@joboet
Copy link
Member Author

joboet commented Oct 10, 2024

This would make that other issue redundant, yes, although the API is different.

@RalfJung
Copy link
Member

RalfJung commented Oct 10, 2024 via email

@RalfJung
Copy link
Member

Looking at rust-lang/rust#122408, there are quite a few functions to be supported here:

pub fn os_sync_wait_on_address(*mut c_void, u64, usize, u32) -> c_int
pub fn os_sync_wait_on_address_with_timeout(*mut c_void, u64, usize, u32, u32, u64) -> c_int
pub fn os_sync_wake_by_address_any(*mut c_void, usize, u32) -> c_int
pub fn os_sync_wake_by_address_all(*mut c_void, usize, u32) -> c_int
pub fn __ulock_wait2(u32, *mut c_void, u64, u64, u64) -> c_int
pub fn __ulock_wait(u32, *mut c_void, u64, u32) -> c_int
pub fn __ulock_wake(u32, *mut c_void, u64) -> c_int

But it also seems there's a sequence of fallbacks so we probably don't need all of them? I'll have to check how weak symbols work on macOS and how Miri can provide them -- on Linux it's fairly easy, we just have global statics of the name and fill them with function pointers. On macOS it seems to boil down to dlsym? That should be easy as well then.

So then it seems like we need just the first four ones, the ones with the "nice" names (not starting with __).

@RalfJung
Copy link
Member

What would help is having a little test program that invokes these APIs and checks basic functionality, with the flags std needs. (Can be direct calls, it's easy to then also make them available via dlsym). Usually I use the standard library to drive the testing but that won't work this time.

We have such a test for futexes at tests/pass-dep/concurrency/linux-futex.rs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-concurrency Area: affects our concurrency (multi-thread) support A-mac Area: Affects only macOS targets A-shims Area: This affects the external function shims C-enhancement Category: a PR with an enhancement or an issue tracking an accepted enhancement
Projects
None yet
Development

No branches or pull requests

2 participants