|
|
|
|
|
|
by tialaramex
1064 days ago
|
|
|
In Rust there's actually deliberately a core library, and so no_std actually makes sense - you get the core library, not the larger std which re-exports all of core plus a lot more. There's quite a lot of stuff in that core library, just nothing that requires an operating system or an allocator. So Rust's Mutex isn't available (how can we provide a mutual exclusion mechanism on the bare hardware?) but Rust's Option<(core::net::IpAddr, core::time::Duration) is available everywhere, it's either None or a pair of an IP (v4 or v6) address and a duration, perhaps some sort of address lease because maybe we're an embedded device which has, or gives out, address leases. In C++ this makes less sense because their standard library does have a defined "freestanding" subset but it doesn't make a very coherent whole, it's roughly the bits that seemed obviously to just not need any other components to work. It changes from version to version. And this stx library replaces what you might think of as core ideas, like an optional type, so you don't keep the shared vocabulary benefit. [Edited to correct "standalone" to "freestanding"] |
|
|
This is a bit misleading. It's easier to provide mutual exclusion on bare hardware than in an OS; just do a spinlock, except with modern ISAs the core doesn't even spin.
Presumably core doesn't offer this because it's a massive footgun for devs new to multithreading who would not understand why this is unacceptable to use in an OS-hosted process.