std: panic instead of deadlocking in mutex implementation on Fuchsia

diff --git a/library/std/src/sys/unix/futex.rs b/library/std/src/sys/unix/futex.rs
index 96b07b510a777da2ffcbd40dfc6b2cb68a31a771..8d5b540212a17c9be272c66d14f6b84a96049c44 100644 (file)
--- a/library/std/src/sys/unix/futex.rs
+++ b/library/std/src/sys/unix/futex.rs
@@ -267,7 +267,6 @@ pub fn zx_futex_wait(
         ) -> zx_status_t;
         pub fn zx_futex_wake(value_ptr: *const zx_futex_t, wake_count: u32) -> zx_status_t;
         pub fn zx_futex_wake_single_owner(value_ptr: *const zx_futex_t) -> zx_status_t;
-        pub fn zx_nanosleep(deadline: zx_time_t) -> zx_status_t;
         pub fn zx_thread_self() -> zx_handle_t;
     }
 }

diff --git a/library/std/src/sys/unix/locks/fuchsia_mutex.rs b/library/std/src/sys/unix/locks/fuchsia_mutex.rs
index 65d7c4eefd99ade0d7d088618e62642c7db37061..7372406b32fac683dba4a8a68a97db4ad2ec4e8c 100644 (file)
--- a/library/std/src/sys/unix/locks/fuchsia_mutex.rs
+++ b/library/std/src/sys/unix/locks/fuchsia_mutex.rs
@@ -42,9 +42,9 @@
     Ordering::{Acquire, Relaxed, Release},
 };
 use crate::sys::futex::zircon::{
-    zx_futex_wait, zx_futex_wake_single_owner, zx_handle_t, zx_nanosleep, zx_thread_self,
-    ZX_ERR_BAD_HANDLE, ZX_ERR_BAD_STATE, ZX_ERR_INVALID_ARGS, ZX_ERR_TIMED_OUT, ZX_ERR_WRONG_TYPE,
-    ZX_OK, ZX_TIME_INFINITE, ZX_TIME_INFINITE,
+    zx_futex_wait, zx_futex_wake_single_owner, zx_handle_t, zx_thread_self, ZX_ERR_BAD_HANDLE,
+    ZX_ERR_BAD_STATE, ZX_ERR_INVALID_ARGS, ZX_ERR_TIMED_OUT, ZX_ERR_WRONG_TYPE, ZX_OK,
+    ZX_TIME_INFINITE, ZX_TIME_INFINITE,
 };
 
 // The lowest two bits of a `zx_handle_t` are always set, so the lowest bit is used to mark the
@@ -122,18 +122,18 @@ fn lock_contested(&self, mut state: u32, thread_self: zx_handle_t) {
                         ZX_TIME_INFINITE,
                     ) {
                         ZX_OK | ZX_ERR_BAD_STATE | ZX_ERR_TIMED_OUT => (),
-                        // Either the current thread is trying to lock a mutex it has already locked,
-                        // or the previous owner did not unlock the mutex before exiting. Since it is
-                        // not possible to reliably detect which is the case, the current thread is
-                        // deadlocked. This makes debugging these cases quite a bit harder, but encourages
-                        // portable programming, since all other platforms do the same.
-                        //
-                        // Note that if the thread handle is reused, an arbitrary thread's priority could
-                        // be boosted by the wait, but there is currently no way to prevent that.
-                        ZX_ERR_INVALID_ARGS | ZX_ERR_BAD_HANDLE | ZX_ERR_WRONG_TYPE => loop {
-                            zx_nanosleep(ZX_TIME_INFINITE);
-                        },
-                        error => unreachable!("unexpected error code in futex wait: {error}"),
+                        // Note that if a thread handle is reused after its associated thread
+                        // exits without unlocking the mutex, an arbitrary thread's priority
+                        // could be boosted by the wait, but there is currently no way to
+                        // prevent that.
+                        ZX_ERR_INVALID_ARGS | ZX_ERR_BAD_HANDLE | ZX_ERR_WRONG_TYPE => {
+                            panic!(
+                                "either the current thread is trying to lock a mutex it has
+                                already locked, or the previous uowner did not unlock the mutex
+                                before exiting"
+                            )
+                        }
+                        error => panic!("unexpected error in zx_futex_wait: {error}"),
                     }
                 }
             }