Crate nb

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 means Async::NotReady
In await mode: WouldBlock means yield (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))?;
}

Crate nb

Core idea

How to use this crate

Examples

A Core I/O API

Blocking mode

Macros

Enums

Type Definitions