Use futex-based synchronization on Apple platforms by joboet · Pull Request #122408 · rust-lang/rust

joboet · 2024-03-12T20:36:51Z

Last week, Apple released macOS version 14.4, which introduced a public futex API called os_sync_wait_on_address (Apple has failed to include the documentation provided in the defining header os/os_sync_wait_on_address.h on its website). As the private API backing these functions has been around since macOS 10.12, our minimum supported version, it can be used as fallback without risking breakage in future versions.

This PR thus switches all other synchronization primitives except Mutex (namely Condvar, RwLock, Once and thread parking) to the futex-based implementations also used on Linux and Windows.

rustbot · 2024-03-12T20:36:58Z

r? @m-ou-se

rustbot has assigned @m-ou-se.
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

BlackHoleFox · 2024-03-13T01:29:57Z

+
+    // These syscalls appeared with macOS 10.12.
+    weak! {
+        pub fn __ulock_wait(u32, *mut c_void, u64, u32) -> c_int


Mind explaining more what the thought process of these going undetected is? Seems like a risky chance that might require a hot fix if the MAS or iOS app store scanners see through this.

In reality I think this won't be enough and we need to call ulock things via syscall directly instead. This means that the "fallback" Apple futex implementation is only going to be usable on macOS.

I know Electron apps on the MAS use direct syscalls to emulate private functions, so this is probably what Rust should do too on macOS with precedence:

#define SYS_ulock_wait 515 #define SYS_ulock_wake 516 #define SYS_ulock_wait2 544

For iOS, detect if the os_sync_ functions are available or fallback to the non-futex implementation :/ Calling a syscall directly is forbidden per the iOS headers so std can't do the same as macOS:

__WATCHOS_PROHIBITED __TVOS_PROHIBITED __OS_AVAILABILITY_MSG(ios,deprecated=10.0,"syscall(2) is unsupported; " "please switch to a supported interface. For SYS_kdebug_trace use kdebug_signpost().") __OS_AVAILABILITY_MSG(macosx,deprecated=10.12,"syscall(2) is unsupported; " "please switch to a supported interface. For SYS_kdebug_trace use kdebug_signpost().") int syscall(int, ...);

This is a "spirit of the law" kind of situation. Apple understandably wants App Store software to continue working in newer versions, so they prohibit private API use, as they want to be able to remove or change that API at will. By only using the private API as fallback and not linking it directly, we fulfil this wish. If we directly linked the private API instead, we'd get dynamic linker errors if they remove it, so we can't do that.

On the other hand, we break the "letter of the law" as we are using private API. In my opinion, this is totally fine and justified, but of course, this is only my interpretation. It would be great if someone from Apple could look over this, just so that we know that they are aware of this. My past attempt at reaching out to them for this has been unsuccessful.

Would you consider the solution of atomic-wait? They use libc++.

https://github.com/m-ou-se/atomic-wait/blob/main/src/macos.rs

But these only exist starting with macOS 11, which is way above our minimum of 10.12, so the ulock fallback would be needed regardless.

This sets precedent for using private APIs in the standard library (our current use of weak! is only used for symbols that are available in newer versions), which I think is a fairly big deal, and should perhaps be discussed more broadly (in a separate issue? (that could be FCP'ed?)).

Somewhat related is #114186. Tagging in particular @thomcc and @workingjubilee, as they seem to have been involved in this kind of stuff before?

At the very least, we should use the dlsym! macro explicitly here, to make it very clear that we're not weakly linking the symbol (which would be very visible in the binary), but actually loading it at runtime, and thereby evading the App Store's checks (dlsym itself seems to be allowed).

I believe this is sufficient such that we do not need to do raw syscalls (which I remember to have caused problems for Go in the past since as the ABI isn't stable (?)).

Yeah, we shouldn't be calling this directly, it'll trip the app store static analysis.

See also discussion in #93740 (comment)

I believe this should be resolved by #122408 (comment).

@joboet would you mind adding reasoning in a code comment, or at least a link to my comment?

BlackHoleFox · 2024-03-13T01:30:23Z

+                wait(UL_COMPARE_AND_WAIT | ULF_NO_ERRNO, addr, value, 0);
+            }
+        } else {
+            panic!("your system is below the minimum supported version of Rust");


These panics also get to be deleted if raw syscalls are used :)

If we do keep the panics, I'd go for an abort here instead, this is not recoverable in any way and avoiding the overhead from unwind landing pads would be nice.

bors · 2024-03-13T10:15:08Z

☔ The latest upstream changes (presumably #122423) made this pull request unmergeable. Please resolve the merge conflicts.

Implement the `os_unfair_lock` functions on macOS These are needed for rust-lang/rust#122408. See the documentation [here](https://developer.apple.com/documentation/os/synchronization?language=objc) and the implementation [here](https://github.com/apple-oss-distributions/libplatform/blob/a00a4cc36da2110578bcf3b8eeeeb93dcc7f4e11/src/os/lock.c#L645).

Implement the `os_unfair_lock` functions on macOS These are needed for rust-lang#122408. See the documentation [here](https://developer.apple.com/documentation/os/synchronization?language=objc) and the implementation [here](https://github.com/apple-oss-distributions/libplatform/blob/a00a4cc36da2110578bcf3b8eeeeb93dcc7f4e11/src/os/lock.c#L645).

madsmtm

In general, nice work, this will be a great perf improvement!

I know it is a draft, but once you're ready, it'd be nice to split the Mutex changes apart from the futex changes, if possible.

@rustbot label O-apple

madsmtm · 2024-09-26T12:21:40Z

+        target_os = "macos",
+        target_os = "ios",
+        target_os = "tvos",
+        target_os = "watchos",


Please use target_vendor = "apple", as that also includes visionOS. Also applies elsewhere.

madsmtm · 2024-09-26T13:01:50Z

+/// See os/os_sync_wait_on_address.h (Apple has failed to upload the documentation
+/// to their website) for documentation of the public API and
+/// https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/bsd/sys/ulock.h#L69
+/// for the header file of the private API, along with its usage in libpthread
+/// https://github.com/apple-oss-distributions/libpthread/blob/d8c4e3c212553d3e0f5d76bb7d45a8acd61302dc/src/pthread_cond.c#L463


I'd also link the design/decision document:
https://github.com/apple-oss-distributions/libplatform/blob/libplatform-316.100.10/docs/expose-futex-style-api.md

madsmtm · 2024-09-26T13:39:47Z

+    if let Some(wake) = os_sync_wake_by_address_any.get() {
+        unsafe { wake(addr, size_of::<u32>(), OS_SYNC_WAKE_BY_ADDRESS_NONE) == 0 }
+    } else if let Some(wake) = __ulock_wake.get() {
+        // __ulock_wake can get interrupted, so retry until either waking up a
+        // waiter or failing because there are no waiters (ENOENT).
+        loop {
+            let r = unsafe { wake(UL_COMPARE_AND_WAIT | ULF_NO_ERRNO, addr, 0) };
+
+            if r >= 0 {
+                return true;
+            } else {
+                match -r {
+                    libc::ENOENT => return false,
+                    libc::EINTR => continue,
+                    err => panic!("__ulock_wake failed: {}", Error::from_raw_os_error(err)),
+                }
+            }
+        }


Hmm, are you sure this is correct? The implementation of os_sync_wake_by_address_any seems to just call __ulock_wake without a loop? So either we need to loop both places, or in none of them?

Same goes for futex_wake.

the8472 · 2024-10-23T17:18:16Z

We discussed this during today's T-libs meeting (albeit with low attendance). We might be willing to go along with the changes on the theory that apps are validated on current OS versions and will use current stable APIs and so shouldn't cause issues and that the fallback APIs have been available for a long time and so won't suddenly disappear on older versions.

But in previous cases where we've started to rely on internal APIs we've leaned on platform experts and their investigations how risky that would be. So we'd like to do the same here. @rustbot ping apple

rustbot · 2024-10-23T17:18:19Z

Hey Apple notification group! This issue or PR could use some Apple-specific
guidance. Could one of you weigh in? Thanks <3

(In case it's useful, here are some instructions for tackling these sorts of
issues).

cc @BlackHoleFox @hkratz @inflation @madsmtm @nvzqz @shepmaster @thomcc

the8472 · 2024-10-23T17:26:55Z

This sets precedent for using private APIs in the standard library (our current use of weak! is only used for symbols that are available in newer versions), which I think is a fairly big deal, and should perhaps be discussed more broadly (in a separate issue? (that could be FCP'ed?)).

We do use internal APIs on windows (NtCreateFile), but that became necessary to fix a CVE and was used after looking at the microsoft ecosystem official projects. And windows is a more open platform in a way (hah) since they don't review most software. So it's not fully comparable.

madsmtm · 2024-10-23T21:36:38Z

on the theory that apps are validated on current OS versions and will use current stable APIs and so shouldn't cause issues and that the fallback APIs have been available for a long time and so won't suddenly disappear on older versions.

Just to be clear, the problematic API here is not so much the newly added APIs (os_sync_wait_on_address etc.), but the fallback implementation for older OS'es (__ulock_wait) that might trip Apple's analysis, and make it very hard for Rust users to submit their application to the App Store.

It would be nice if someone could try to submit an application for review in the App Store that uses this branch of rustc, and see if Apple's review picks up on the usage of __ulock_wait via. dlsym or not, that would appease most of my worries here.

madsmtm · 2025-08-26T19:30:10Z

I've been talking with a friend who has an app in the App Store, and got him to submit a few different versions of his app using various private symbols in different ways as a test (basically probing the black box), still waiting on the last result, give me a few weeks.

madsmtm · 2025-10-14T23:42:42Z

Hey again. I got a friend (thanks a lot @extrawurst!) who has a live app in the Apple App Store to submit a few modified version of said app, as a way to probe whether they could pass App Store's opaque review process.

Note that test 1-4 was done sometime around March IIRC, while test 5 was done ~a week ago when we picked this up again, so it is possible that the App Store changed how things work in the meantime.

Theories

There are roughly three ways that a check like this could work:

String-level check for these symbols.
Inspect the binary using objdump or similar.
Execute the binary and do a runtime check.

Note that these are not mutually exclusive; the App Store may do one thing for some symbols, and another for other symbols. And they may do different things for e.g. compiled objects vs. Python files.

Also note that the check could be either an allowlist or a denylist.

Tests

Test 1

Using dlsym to look up the symbols (same as what this PR does).

Code

use core::ffi::{c_char, c_void};
use core::ptr::null_mut;

extern "C" {
    fn dlsym(handle: *mut c_void, symbol: *const c_char) -> *mut c_void;
}

fn main() {
    unsafe {
        let _ = dlsym(null_mut(), c"__ulock_wait2".as_ptr());
        let _ = dlsym(null_mut(), c"__ulock_wait".as_ptr());
        let _ = dlsym(null_mut(), c"__ulock_wake".as_ptr());
    }

    // Rest of normal application calling `UIApplicationMain`.
}

Result: Succeeded!

Test 2

Directly linking __ulock_wait2, __ulock_wait and __ulock_wake.

Code

use core::ffi::{c_int, c_void};
use core::ptr::null_mut;

extern "C" {
    fn __ulock_wait2(operation: u32, addr: *mut c_void, value: u64, timeout: u64, value2: u64) -> c_int;
    fn __ulock_wait(operation: u32, addr: *mut c_void, value: u64, timeout: u32) -> c_int;
    fn __ulock_wake(operation: u32, addr: *mut c_void, wake_value: u64) -> c_int;
}

fn main() {
    if std::hint::black_box(false) {
        __ulock_wait(0, null_mut(), 0, 0);
        __ulock_wait2(0, null_mut(), 0, 0, 0);
        __ulock_wake(0, null_mut(), 0);
    }

    // Rest of normal application calling `UIApplicationMain`.
}

Result: Succeeded!

Test 3

Directly linking other private symbols from libSystem.dylib.

Code

use core::ffi::{c_char, c_int, c_uint};
use core::ptr::null_mut;

extern "C" {
    fn __openat(fd: c_int, path: *const c_char, oflag: c_int, mode: u16) -> c_int;
    fn _get_cpu_capabilities() -> u64;
    fn _kernelrpc_mach_vm_allocate(target: c_uint, address: *mut u32, size: u64, flags: c_int) -> c_int;
    fn _dispatch_get_main_queue_port_4CF() -> c_uint;
    fn dyld_dynamic_interpose(mh: *const c_void, dyld_interpose_tuple: *const c_void, count: isize);
}

fn main() {
    if std::hint::black_box(false) {
        let _ = __openat(0, null_mut(), 0, 0);
        let _ = _get_cpu_capabilities();
        let _ = _kernelrpc_mach_vm_allocate(0, null_mut(), 0, 0);
        let _ = _dispatch_get_main_queue_port_4CF();
        let _ = dyld_dynamic_interpose(null_mut(), null_mut(), 0);
    }

    // Rest of normal application calling `UIApplicationMain`.
}

Result: Failed with:

[Application Loader Error Output]: [ContentDelivery.Uploader.REDACTED] Validation failed (409) The app references non-public symbols in Payload/REDACTED.app/REDACTED: __dispatch_get_main_queue_port_4CF, _dyld_dynamic_interpose

Test 4

Directly linking private symbols from test 3 that didn't seem to fail.

Code

use core::ffi::c_int;
use core::ptr::null_mut;

extern "C" {
    fn __openat(fd: c_int, path: *const c_char, oflag: c_int, mode: u16) -> c_int;
    fn _get_cpu_capabilities() -> u64;
    fn _kernelrpc_mach_vm_allocate(target: c_uint, address: *mut u32, size: u64, flags: c_int) -> c_int;
}

fn main() {
    if std::hint::black_box(false) {
        let _ = __openat(0, null_mut(), 0, 0);
        let _ = _get_cpu_capabilities();
        let _ = _kernelrpc_mach_vm_allocate(0, null_mut(), 0, 0);
    }

    // Rest of normal application calling `UIApplicationMain`.
}

Result: Succeeded!

Test 5

Dynamically linking known private symbols from libSystem.dylib.

Code

use core::ffi::{c_char, c_void};
use core::ptr::null_mut;

extern "C" {
    fn dlsym(handle: *mut c_void, symbol: *const c_char) -> *mut c_void;
}

fn main() {
    unsafe {
        let _ = dlsym(null_mut(), c"_dispatch_get_main_queue_port_4CF".as_ptr());
        let _ = dlsym(null_mut(), c"dyld_dynamic_interpose".as_ptr());
    }

    // Rest of normal application calling `UIApplicationMain`.
}

Result: Succeeded!

Analysis

It seems to me that the App Store's checks around private-ness (at least for functions in libSystem.dylib) may take more of a denylist than an allowlist approach, and that __ulock_wait2, __ulock_wait and __ulock_wake happen to not be denied. I'm basing this on test 3 failing, which shows that they do detect usage of some private APIs like _dispatch_get_main_queue_port_4CF, while test 2 and 4 succeeds, and I can't imagine they'd want to explicitly allowlist e.g. _kernelrpc_mach_vm_allocate which is also very private API.

Additionally, based on test 5, it seems like the days of dlsym failing is over (which they did do in the past as @BlackHoleFox noted), and that the App Store at least nowadays inspects the binary for linkage instead of just searching for denied strings. Test 5 also shows that the App Store doesn't do runtime checking of denylisted APIs.

All of this really is probing a black box function though. Possible failure modes:

The App Store's checks were loosened between March and September, we'd have to re-run test 3 to be sure.
The App Store's checks are non-deterministic (e.g. only 10% of applications with the symbols are flagged).
Fewer restrictions on iOS than tvOS/watchOS/visionOS.
Something specific to my friend's app (geolocation-based? Maybe the checks are less strict in the EU?).
Future changes to the checks may cause this to fail in the future.

Conclusion

I believe the risk is sufficiently low that it should be safe for us to move forwards with this.

Given the results above test, we could probably use weak linking for the __ulock* symbols, but to be safe, I'd prefer we keep using dlsym for those. I don't think we have to obfuscate the string though.

I realized just now that I can also just try to ask Apple what they think, I have filed FB20671640 for that, will post a response here if I get one (but I think it's safe for us to move forwards with this without waiting for a response).

madsmtm · 2025-10-14T23:46:48Z

Sorry for blocking this for so long!

@rustbot author (rebase + a few unresolved comments)

Also, please CC me once/if you get around to filing the follow-up that replaces Mutex as well.

rustbot · 2025-11-06T18:24:19Z

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

rustbot · 2025-11-06T18:24:22Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

joboet · 2025-11-06T18:26:20Z

@rustbot label +S-waiting-on-team -S-waiting-on-author

orlp · 2025-12-22T12:48:40Z

+            }
+        }
+    } else {
+        panic!("your system is below the minimum supported version of Rust");


This panic should be a rtabort!.

orlp · 2025-12-22T12:50:47Z

+        target_os = "macos",
+        target_os = "ios",
+        target_os = "tvos",
+        target_os = "watchos",


Is there a reason this block doesn't use target_vendor = "apple" like the other blocks?

orlp · 2025-12-22T12:56:34Z

@joboet I had the above two concerns, and I believe there are also some unresolved concerns above from @madsmtm regarding the looping of __ulock_wake and linking of a design document in a comment.

Could you resolve these? Then hopefully we can merge.

ephraimkunz · 2025-12-24T03:53:42Z

+            match super::os::errno() {
+                // There were no waiters to wake up.
+                libc::ENOENT => false,
+                err => rtabort!("__ulock_wake failed: {}", Error::from_raw_os_error(err)),


Suggested change

err => rtabort!("__ulock_wake failed: {}", Error::from_raw_os_error(err)),

err => rtabort!("os_sync_wake_by_address_any failed: {}", Error::from_raw_os_error(err)),

ephraimkunz · 2025-12-24T04:10:16Z

+                )
+            };
+
+            // We promote spurious wakeups (reported as EINTR) to normal ones for


Is this comment accurate? The documentation doesn't list EINTR as a valid error return.

Ah, nevermind. The documentation doesn't list this but the header does: https://gist.github.com/BlackHoleFox/00ca98a94fc75e7c48418a0685f4d050#file-os_sync_wait_on_address-h-L132

the8472 · 2026-01-07T17:26:26Z

@madsmtm

I realized just now that I can also just try to ask Apple what they think, I have filed FB20671640 for that

Any news on that?

Amanieu · 2026-04-22T16:03:53Z

We discussed this in the @rust-lang/libs meeting. We are choosing to reject this as-is. Realistically, we're never going to get official permission from Apple to use a private API and we don't feel comfortable relying on it directly.

Instead we recommend that the same be achieved by linking against libc++.so on Apple platforms. This is a system library (which is allowed to use private APIs) that provides __libcpp_atomic_* symbols for C++20 atomic support. Since this is only available on macOS 11, we will need to bump our minimum supported OS version for Apple targets. This shouldn't be a problem since that was released in 2020.

thomcc · 2026-04-22T18:31:15Z

People (not uncommonly) statically link libc++, even on Apple platforms. (It doesn't use the private APIs in such cases and uses a slower fallback instead, but it can provide access to newer C++ APIs than are available in the system-distributed libc++). If libstd dynamically links libc++, it might cause problems for those people.

I think we really want to use the libc++ APIs, we should only do so via dlsym (against dlopen("libc++.so", RTLD_LOCAL)), and even then, only after we try to dlsym use the new os_sync_* APIs (either via dlsym or extern_weak).

Amanieu · 2026-04-22T20:18:06Z

(It doesn't use the private APIs in such cases and uses a slower fallback instead, but it can provide access to newer C++ APIs than are available in the system-distributed libc++)

It seems to always use the private API and doesn't seem to have a fallback: https://github.com/llvm/llvm-project/blob/97015ad916c48ddf0fa34a4801e2851230cf5070/libcxx/src/atomic.cpp#L97

madsmtm · 2026-04-22T21:08:27Z

A bit of further context, I opened a Zulip thread in t-compiler/private (this was the only private channel I was in at the time) to discuss Apple's response to FB20671640 (which was basically "no, you are not allowed to circumvent the App Store rules for this"). For those with access, it's here.

The takeaway there was "we need more direct contact with Apple", going through the Feedback Assistant is not the way to do this. We talked a bit about how to do so, a good suggestion for that was to try to contact some of the LLVM developers with @apple.com emails.

I... said I'd do that, and I never got around to doing so, I think I was feeling discouraged by the whole situation. Sorry about that, I guess that ended up blocking this issue again :/. I still think that's a good idea, and I would still like to do it, but realistically, I'm probably not going to find the motivation for it anytime soon.

So I agree with t-libs' decision here: Until we get a statement from someone at Apple that we're allowed to do this, we shouldn't.

madsmtm · 2026-04-22T21:08:42Z

Since this is only available on macOS 11, we will need to bump our minimum supported OS version for Apple targets. This shouldn't be a problem since that was released in 2020.

I'm pretty strongly against bumping the minimum OS version for various reasons (I've outlined some of them in the previous version bump in #104385).

I think the best path forwards for this would be to wait for rust-lang/rfcs#3750. That would allow us to write it like:

cfg_select! {
    any(
        target_version("macos", "14.4"),
        target_version("ios", "17.4"),
        target_version("tvos", "17.4"),
        target_version("visionos", "1.1"),
        target_version("watchos", "10.4"),
    ) => {
        // ... os_sync_wait_on_address impl
    }
    _ => {
        // ... current pthread impl
    }
}

Which would allow supporting both (though it would require -Zbuild-std).

Alternatively, it's possible we could have both impls in an enum or something, and try os_sync_wait_on_address at runtime first, and then fall back to pthread if it's not available.

thomcc · 2026-04-25T15:22:42Z

It seems to always use the private API and doesn't seem to have a fallback: https://github.com/llvm/llvm-project/blob/97015ad916c48ddf0fa34a4801e2851230cf5070/libcxx/src/atomic.cpp#L97

Huh, you're right, I was misremembering. I could have sworn there was a check that it was part of the dylib, but it seems that while it used to be conditional, it was conditional on apple target version. Either way, this will still likely cause problems for people who statically link libc++, which is not exactly rare (I've done it with bazel using https://github.com/bazel-contrib/toolchains_llvm, and zig c++ does it by default).

joboet added the A-atomic Area: Atomics, barriers, and sync primitives label Mar 12, 2024

joboet marked this pull request as draft March 12, 2024 20:36

rustbot assigned m-ou-se Mar 12, 2024

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 Mar 12, 2024

joboet mentioned this pull request Mar 12, 2024

Tracking issue for improving std::sync::{Mutex, RwLock, Condvar} #93740

Closed

63 tasks

BlackHoleFox suggested changes Mar 13, 2024

View reviewed changes

joboet added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 8, 2024

RalfJung mentioned this pull request Apr 18, 2024

Implement macOS dispatch semaphores rust-lang/miri#2589

Open

This was referenced Jul 9, 2024

macOS: add os_sync_wait_on_address and related definitions rust-lang/libc#3769

Merged

Implement the os_unfair_lock functions on macOS rust-lang/miri#3745

Merged

madsmtm requested changes Sep 26, 2024

View reviewed changes

rustbot added O-apple Operating system: Apple / Darwin (macOS, iOS, tvOS, visionOS, watchOS) labels Sep 26, 2024

RalfJung mentioned this pull request Sep 29, 2024

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

Open

joboet mentioned this pull request Oct 10, 2024

Shim the macOS futex API rust-lang/miri#3962

Closed

joboet added the I-libs-nominated Nominated for discussion during a libs team meeting. label Oct 10, 2024

Dylan-DPC added S-waiting-on-team and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Oct 14, 2024

joshtriplett added the relnotes Marks issues that should be documented in the release notes of the next release. label Nov 6, 2024

rustbot 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 Oct 14, 2025

joboet added 2 commits November 5, 2025 16:16

std: allow weak in item position on Apple platforms

1c82aa7

std: use futex for everything but Mutex on Apple platforms

dc7c2b6

joboet force-pushed the apple_futex branch from dc49e21 to dc7c2b6 Compare November 6, 2025 18:24

rustbot added the A-meta Area: Issues & PRs about the rust-lang/rust repository itself label Nov 6, 2025

rustbot added S-waiting-on-team and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 6, 2025

orlp suggested changes Dec 22, 2025

View reviewed changes

ephraimkunz reviewed Dec 24, 2025

View reviewed changes

Urgau added S-waiting-on-t-libs Status: Awaiting decision from T-libs and removed S-waiting-on-team labels Dec 28, 2025

joboet mentioned this pull request Jan 25, 2026

Atomic missing wait and notify_* while C++20 supports that #151644

Closed

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-t-libs Status: Awaiting decision from T-libs labels Apr 22, 2026

	err => rtabort!("__ulock_wake failed: {}", Error::from_raw_os_error(err)),
	err => rtabort!("os_sync_wake_by_address_any failed: {}", Error::from_raw_os_error(err)),

Uh oh!

Conversation

joboet commented Mar 12, 2024 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 12, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

madsmtm Sep 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

madsmtm Sep 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bors commented Mar 13, 2024

Uh oh!

madsmtm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

the8472 commented Oct 23, 2024

Uh oh!

rustbot commented Oct 23, 2024

Uh oh!

the8472 commented Oct 23, 2024

Uh oh!

madsmtm commented Oct 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

madsmtm commented Aug 26, 2025

Uh oh!

madsmtm commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Theories

Tests

Test 1

Test 2

Test 3

Test 4

Test 5

Analysis

Conclusion

Uh oh!

madsmtm commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Nov 6, 2025

Uh oh!

rustbot commented Nov 6, 2025

Uh oh!

joboet commented Nov 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

joboet commented Mar 12, 2024 •

edited by rustbot

Loading

madsmtm Sep 26, 2024 •

edited

Loading

madsmtm Sep 26, 2024 •

edited

Loading

madsmtm commented Oct 23, 2024 •

edited

Loading

madsmtm commented Oct 14, 2025 •

edited

Loading

madsmtm commented Oct 14, 2025 •

edited

Loading

orlp commented Dec 22, 2025 •

edited

Loading

ephraimkunz Dec 24, 2025 •

edited

Loading

madsmtm commented Apr 22, 2026 •

edited

Loading

madsmtm commented Apr 22, 2026 •

edited

Loading