smarm
7746dca69b
While running benchmarks, a hang surfaced in timer-only workloads — actors sleeping with no IO in flight. Tracing it down, the race lives in sleep(): between the call to `timers.insert_sleep` and the subsequent `park_current` yield, the actor is still in State::Runnable. If the timer fires in that window, the old code's `if matches!(slot.state, State::Parked)` guard silently drops the wakeup. The actor then parks normally and never gets re-queued — it sleeps forever. The fix mirrors what scheduler::unpark() and the IO FdReady path already do: when the timer fires and the slot is still Runnable, set `pending_unpark` instead of re-queuing immediately. The upcoming Park yield sees the flag and re-queues the actor rather than suspending it, closing the race without any new synchronisation. Adds a regression test: 100 actors doing pure timer sleeps across ≥2 scheduler threads. The test asserts both correctness (all actors complete) and timeliness (wall time < 2×sleep duration), which is enough signal to catch a stuck actor even on a single-core CI runner.
44 lines
601 B
TOML
44 lines
601 B
TOML
[package]
|
|
name = "smarm"
|
|
version = "0.3.0"
|
|
edition = "2021"
|
|
rust-version = "1.95"
|
|
|
|
[features]
|
|
smarm-trace = []
|
|
|
|
[dependencies]
|
|
libc = "0.2"
|
|
|
|
[dev-dependencies]
|
|
libc = "0.2"
|
|
tokio = { version = "1", features = ["rt", "rt-multi-thread", "macros", "sync", "time"] }
|
|
|
|
[profile.dev]
|
|
panic = "unwind"
|
|
|
|
[profile.release]
|
|
panic = "unwind"
|
|
lto = "thin"
|
|
codegen-units = 1
|
|
|
|
[[bench]]
|
|
name = "primes"
|
|
harness = false
|
|
|
|
[[bench]]
|
|
name = "multi_scheduler"
|
|
harness = false
|
|
|
|
[[bench]]
|
|
name = "general"
|
|
harness = false
|
|
|
|
[[bench]]
|
|
name = "smarm_favored"
|
|
harness = false
|
|
|
|
[[bench]]
|
|
name = "tokio_favored"
|
|
harness = false
|