1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
//! Fail-closed locking for scheduler shared state.
//!
//! # Why we do **not** recover from poison
//!
//! `std::sync::Mutex` marks itself poisoned when a thread panics while holding
//! the guard. That means the protected value *may* be mid-update
//! (directory shard, mailbox queue, supervisor tables, oneshot slot, …).
//!
//! Silently calling `PoisonError::into_inner()` and continuing is the wrong
//! trade-off for a concurrent runtime: you schedule and deliver messages
//! against potentially inconsistent tables. High-integrity practice
//! (fail closed) is to abort the operation with a loud diagnostic so the
//! fault cannot cascade as silent corruption.
//!
//! flow-level panics are already isolated by `catch_unwind` around
//! `Vm::run` and never hold these locks across that boundary. Poison here
//! therefore implies a **scheduler / host bug**, not a buggy actor.
//!
//! These helpers return [`RuntimeError::PoisonedLock`] instead of panicking
//! so worker loops can [`report_fault`] and exit cleanly, and API boundaries
//! can propagate `Result`. We still never call `into_inner()`.
use ;
use Duration;
use RuntimeError;
/// Acquire `m`, or [`RuntimeError::PoisonedLock`] (integrity fault).
pub
/// Wait on `cvar`, or poison error if the wait observes a poisoned mutex.
pub
/// Timed wait, or poison error if the wait observes a poisoned mutex.
pub