I've had the idea of designing Sans I/O protocols using Rust async/await concept for preparing a state machine. I've prepared the crate to find if this could have better developer experience. The crate brings this concept to experiment: asansio@crates.io

Sample usage could be described like this:

struct Request<'a>(&'a [u8]);
struct Response<'a>(&'a [u8]);

async fn sans_task<'a>(sans: Sans<Request<'a>, Response<'a>>) {
    let mut request_buf = [1u8; 10];
    let response = sans.start(&Request(&request_buf)).await;
    assert_eq!(response.response().unwrap().0, [2; 20]);

    request_buf.fill(3);
    let response = sans.handle(response, &Request(&request_buf)).await;
    assert_eq!(response.response().unwrap().0, [4; 20]);
}

let (sans, io) = asansio::new();

let task = pin!(sans_task(sans));

let request = io.start(task).unwrap();
assert_eq!(request.request().unwrap().0, [1; 10]);

let mut response_buf = [2; 20];
let request = io.handle(request, &Response(&response_buf)).unwrap();
assert_eq!(request.request().unwrap().0, [3; 10]);

response_buf.fill(4);
assert!(io.handle(request, &Response(&response_buf)).is_none());

In the real cases you'd use enums, see examples for tlv/pingpong for std/tokio.

The crate could be useful also in other cases when you need to create a state machine with clear communication around Request/Response enum/struct messages.

The next steps are checking API for developer experience, safety, benchmarks.

3 posts - 2 participants

Read full topic