Expand description
Minimal and reusable non-blocking I/O layer
The ultimate goal of this crate is code reuse. With this crate you can
write core I/O APIs that can then be adapted to operate in either blocking
or non-blocking manner. Furthermore those APIs are not tied to a particular
asynchronous model and can be adapted to work with the futures
model or
with the async
/ await
model.
§Core idea
The WouldBlock
error variant signals that the operation
can’t be completed right now and would need to block to complete.
WouldBlock
is a special error in the sense that’s not
fatal; the operation can still be completed by retrying again later.
nb::Result
is based on the API of
std::io::Result
,
which has a WouldBlock
variant in its
ErrorKind
.
We can map WouldBlock
to different blocking and
non-blocking models:
- In blocking mode:
WouldBlock
means try again right now (i.e. busy wait) - In
futures
mode:WouldBlock
meansAsync::NotReady
- In
await
mode:WouldBlock
meansyield
(suspend the generator)
§How to use this crate
Application specific errors can be put inside the Other
variant in the
nb::Error
enum.
So in your API instead of returning Result<T, MyError>
return
nb::Result<T, MyError>
enum MyError {
ThisError,
ThatError,
// ..
}
// This is a blocking function, so it returns a normal `Result`
fn before() -> Result<(), MyError> {
// ..
}
// This is now a potentially (read: *non*) blocking function so it returns `nb::Result`
// instead of blocking
fn after() -> nb::Result<(), MyError> {
// ..
}
You can use Infallible
to signal that some API has no fatal
errors but may block:
use core::convert::Infallible;
// This returns `Ok(())` or `Err(nb::Error::WouldBlock)`
fn maybe_blocking_api() -> nb::Result<(), Infallible> {
// ..
}
Once your API uses nb::Result
you can leverage the block!
, macro
to adapt it for blocking operation, or handle scheduling yourself.
§Examples
§A Core I/O API
Imagine the code (crate) below represents a Hardware Abstraction Layer for some microcontroller (or microcontroller family).
In this and the following examples let’s assume for simplicity that peripherals are treated as global singletons and that no preemption is possible (i.e. interrupts are disabled).
// This is the `hal` crate
use nb;
/// An LED
pub struct Led;
impl Led {
pub fn off(&self) {
// ..
}
pub fn on(&self) {
// ..
}
}
/// Serial interface
pub struct Serial;
pub enum Error {
Overrun,
// ..
}
impl Serial {
/// Reads a single byte from the serial interface
pub fn read(&self) -> nb::Result<u8, Error> {
// ..
}
/// Writes a single byte to the serial interface
pub fn write(&self, byte: u8) -> nb::Result<(), Error> {
// ..
}
}
/// A timer used for timeouts
pub struct Timer;
impl Timer {
/// Waits until the timer times out
pub fn wait(&self) -> nb::Result<(), Infallible> {
//^ NOTE the `Infallible` indicates that this operation can block but has no
// other form of error
// ..
}
}
§Blocking mode
Turn on an LED for one second and then loops back serial data.
use core::convert::Infallible;
use nb::block;
use hal::{Led, Serial, Timer};
// Turn the LED on for one second
Led.on();
block!(Timer.wait())?;
Led.off();
// Serial interface loopback
loop {
let byte = block!(Serial.read())?;
block!(Serial.write(byte))?;
}
§Features
defmt-0-3
- unstable feature which adds [defmt::Format
] impl forError
.
Macros§
- Turns the non-blocking expression
$e
into a blocking operation.
Enums§
- A non-blocking error
Type Aliases§
- A non-blocking result