Skip to content

Commit f357926

Browse files
committed
std: panic instead of deadlocking in mutex implementation on Fuchsia
1 parent 0d91b08 commit f357926

File tree

2 files changed

+15
-16
lines changed

2 files changed

+15
-16
lines changed

library/std/src/sys/unix/futex.rs

-1
Original file line numberDiff line numberDiff line change
@@ -267,7 +267,6 @@ pub mod zircon {
267267
) -> zx_status_t;
268268
pub fn zx_futex_wake(value_ptr: *const zx_futex_t, wake_count: u32) -> zx_status_t;
269269
pub fn zx_futex_wake_single_owner(value_ptr: *const zx_futex_t) -> zx_status_t;
270-
pub fn zx_nanosleep(deadline: zx_time_t) -> zx_status_t;
271270
pub fn zx_thread_self() -> zx_handle_t;
272271
}
273272
}

library/std/src/sys/unix/locks/fuchsia_mutex.rs

+15-15
Original file line numberDiff line numberDiff line change
@@ -42,9 +42,9 @@ use crate::sync::atomic::{
4242
Ordering::{Acquire, Relaxed, Release},
4343
};
4444
use crate::sys::futex::zircon::{
45-
zx_futex_wait, zx_futex_wake_single_owner, zx_handle_t, zx_nanosleep, zx_thread_self,
46-
ZX_ERR_BAD_HANDLE, ZX_ERR_BAD_STATE, ZX_ERR_INVALID_ARGS, ZX_ERR_TIMED_OUT, ZX_ERR_WRONG_TYPE,
47-
ZX_OK, ZX_TIME_INFINITE, ZX_TIME_INFINITE,
45+
zx_futex_wait, zx_futex_wake_single_owner, zx_handle_t, zx_thread_self, ZX_ERR_BAD_HANDLE,
46+
ZX_ERR_BAD_STATE, ZX_ERR_INVALID_ARGS, ZX_ERR_TIMED_OUT, ZX_ERR_WRONG_TYPE, ZX_OK,
47+
ZX_TIME_INFINITE, ZX_TIME_INFINITE,
4848
};
4949

5050
// 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 @@ impl Mutex {
122122
ZX_TIME_INFINITE,
123123
) {
124124
ZX_OK | ZX_ERR_BAD_STATE | ZX_ERR_TIMED_OUT => (),
125-
// Either the current thread is trying to lock a mutex it has already locked,
126-
// or the previous owner did not unlock the mutex before exiting. Since it is
127-
// not possible to reliably detect which is the case, the current thread is
128-
// deadlocked. This makes debugging these cases quite a bit harder, but encourages
129-
// portable programming, since all other platforms do the same.
130-
//
131-
// Note that if the thread handle is reused, an arbitrary thread's priority could
132-
// be boosted by the wait, but there is currently no way to prevent that.
133-
ZX_ERR_INVALID_ARGS | ZX_ERR_BAD_HANDLE | ZX_ERR_WRONG_TYPE => loop {
134-
zx_nanosleep(ZX_TIME_INFINITE);
135-
},
136-
error => unreachable!("unexpected error code in futex wait: {error}"),
125+
// Note that if a thread handle is reused after its associated thread
126+
// exits without unlocking the mutex, an arbitrary thread's priority
127+
// could be boosted by the wait, but there is currently no way to
128+
// prevent that.
129+
ZX_ERR_INVALID_ARGS | ZX_ERR_BAD_HANDLE | ZX_ERR_WRONG_TYPE => {
130+
panic!(
131+
"either the current thread is trying to lock a mutex it has
132+
already locked, or the previous uowner did not unlock the mutex
133+
before exiting"
134+
)
135+
}
136+
error => panic!("unexpected error in zx_futex_wait: {error}"),
137137
}
138138
}
139139
}

0 commit comments

Comments
 (0)