From 2b9ee8b4217ffbc7e6df405f68be7114b5653537 Mon Sep 17 00:00:00 2001 From: joboet Date: Sun, 14 Jul 2024 19:04:03 +0200 Subject: [PATCH] be even more explicit about what happens when copying `os_unfair_lock` Co-authored-by: Ralf Jung --- tests/pass-dep/concurrency/apple-os-unfair-lock.rs | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/pass-dep/concurrency/apple-os-unfair-lock.rs b/tests/pass-dep/concurrency/apple-os-unfair-lock.rs index cb104d2e7e..c2b9c37bbf 100644 --- a/tests/pass-dep/concurrency/apple-os-unfair-lock.rs +++ b/tests/pass-dep/concurrency/apple-os-unfair-lock.rs @@ -14,8 +14,10 @@ fn main() { libc::os_unfair_lock_assert_not_owner(lock.get()); } - // `os_unfair_lock`s can be moved and leaked, even when locked, - // as long as no operation is occurring on the lock: + // `os_unfair_lock`s can be moved and leaked. + // In the real implementation, even moving it while locked is possible + // (and "forks" the lock, i.e. old and new location have independent wait queues); + // Miri behavior differs here and anyway none of this is documented. let lock = lock; let locked = unsafe { libc::os_unfair_lock_trylock(lock.get()) }; assert!(locked);