Skip to main content

What good is a queue you can't call "push" on, or a mutex you can't "lock?"

It turns out that some common API patterns are bug generators in async Rust code. In the 0.3 release series, I've taken a pass over the OS APIs in lilos (my async embedded OS ) and tried to make the whole OS strictly cancel-safe.

As a side effect, I replaced both "push" and "lock" with subtly different operations that are much harder to use incorrectly. Details in my latest post:

cliffle.com/blog/lilos-cancel-…

#rust

Mutex without lock, Queue without push: cancel safety in lilos - Cliffle

cliffle.com
#rust
in reply to cliffle

Matt Campbell
Matt Campbell
• •
Am I correct in saying that lilos is, at least in some ways, the opposite of what you did with Hubris at Oxide, specifically, async rather than synchronous? I know you developed lilos first, but I'm curious about why you're still working on it after having chosen a very different design for Hubris. Different use cases, or just exploring different design tradeoffs?
⇧