Crate par

What’s a session type, anyway? It’s a description an entire external behavior of a concurrent, message-passing process. From the first message, through every possible path and interaction that can be made with it, to all the ways it can finish.

When implementing a concurrent program according to a session type, the type tells what can happen at any point in the program. When we have to send a message, when to select a path to continue, when to wait for someone else to make a choice and adapt.

Crucially, the types are designed to provide some useful guarantees:

• Protocol adherence – Expectations delivered, obligations fulfilled.
• Deadlock freedom – Cyclic communication is statically ruled out.

Protocol adherence means that when interacting with a process described by a session type, we can be sure (unless it crashes) that it will behave according to the protocol specified by its type. There will no unexpected messages, nor forgotten obligations. Just like we can rely on a function to return a string if it says so, we can rely on a process to send a string if its specified anywhere within its session type.

Deadlock freedom means that deadlocks can’t happen, without dirty tricks anyway. It is achieved by imposing a certain structure on how processes are connected. It can take a bit of getting used to, but it becomes very important when implementing very complex concurrent systems.

❓ Reading this, one may easily think, “I don’t see deadlocks happen in practice…”, and that’s a valid objection! But it arises from our concurrent systems not being very complex due to a lack of tools and types to design and implement them reliably. At high levels of complexity, deadlocks become an issue, and having them ruled out proves crucial.

Using session types, complex concurrent systems can be modelled and implemented with confidence, as any type-checked program is guaranteed to adhere to its protocol, and avoid any deadlocks. Message passing itself ensures natural synchronization.

Lastly, session types give names to concurrent concepts and patterns, which enables high levels of abstraction and composability. That makes it easier to reason and talk about large concurrent systems.

📚 The particular flavor of session types presented here is a full implementation of propositional linear logic. However, no knowledge of linear logic is required to use or understand this library.

Forking

Communication involves two opposing points of view. For example, an exchange of a message is seen as sending on one side, and receiving on the other. The idea extends to larger communication protocols. A turn-based game between two players looks like “my move, your move” by one player, and “your move, my move” by their opponent. Other examples are “a player and the environment”, “a customer and a shop assistant”, “a server and a client”.

A type implementing the Session trait can be thought of as a handle to one of the two viewpoints of a certain communication protocol. Its associated type Dual represents the other side, cleverly restricted as Session<Dual = Self>, so that the two types form a dual pair. A concrete Session and its dual together describe a protocol.

For example, Recv<T> and Send<T> from the exchange module form such a pair.

A session handle can only be created together with its dual, and only in two independent visibility scopes. The former ensures protocol adherence – the other side is always there –, while the latter prevents deadlocks – different visibility scopes enable independent progress.

This moment of creation is called forking. The Session trait has its fork_sync method for this purpose.

use par::{exchange::{Recv, Send}, Session};

async fn forking() {
    let receiver: Recv<i64> = Recv::fork_sync(|sender: Send<i64>| {
        // scope of Send<i64>
        sender.send1(7);
    });
    // scope of Recv<i64>
    assert_eq!(receiver.recv1().await, 7);
}

The function passed to fork_sync is not asynchronous and is fully executed before fork_sync returns. Many useful combinators do not require async: offering only async forking would hurt those. Additionally, it enables the core library to be agnostic about the choice of an async/await runtime.

However, in an application, we usually want the two sides to run concurrently. To do that, we spawn a coroutine/thread inside the synchronous function. For example, with Tokio:

let sender: Send<i64> = Send::fork_sync(|receiver: Recv<i64>| {
    drop(tokio::spawn(async {
        assert_eq!(receiver.recv1().await, 7);
    }))
});
sender.send1(7);

To make life easier, this crate provides utility modules for forking using popular runtimes. With these, the above can be reduced to:

use par::runtimes::tokio::fork;

let sender: Send<i64> = fork(|receiver: Recv<i64>| async {
    assert_eq!(receiver.recv1().await, 7);
});
sender.send1(7);

❗️ Session end-points must not be dropped. (TODO: explain…)

Now we will take a look at three basic ways to compose sessions: sequencing, branching, and recursion. These, together with Recv and Send, are enough to construct any complex session types (within the possibilities of the present framework). The other modules, queue and server, merely standardize some (very useful) patterns.

Sequencing

The two session types above, Recv and Send actually take a second generic parameter: the continuation of the session. This continuation defaults to () if we leave it out.

pub struct Recv<T, S: Session = ()> { /* private fields */ }
pub struct Send<T, S: Session = ()> { /* private fields */ }

The unit type () implements Session and represents an empty, finished session. It’s self-dual, its dual is ().

We can choose different continuations to make sequential sessions. For example:

use par::{exchange::{Recv, Send}, Session};

type Calculator = Send<i64, Send<Op, Send<i64, Recv<i64>>>>;
enum Op { Plus, Times }

Here we have a session which is sending two numbers and an operator, and finally receives a number back, presumably the result.

To get a dual of a sequential session, we also have to dualize the continuation. In the end, we just flip every Recv to Send and vice versa.

The dual of the Calculator session is then Recv<i64, Recv<Op, Recv<i64, Send<i64>>>>.

Here’s one possible implementation:

use par::{runtimes::tokio::fork, Dual};

type User = Dual<Calculator>;  // Recv<i64, Recv<Op, Recv<i64, Send<i64>>>>

fn start_calculator() -> Calculator {
    fork(|user: User| async {
        let (x, user) = user.recv().await;
        let (op, user) = user.recv().await;
        let (y, user) = user.recv().await;
        let result = match op {
            Op::Plus => x + y,
            Op::Times => x * y,
        };
        user.send1(result);
    })
}

async fn calculate() {
    let sum = start_calculator()
        .send(3)
        .send(Op::Plus)
        .send(4)
        .recv1()
        .await;

    let product = start_calculator()
        .send(3)
        .send(Op::Times)
        .send(4)
        .recv1()
        .await;

    assert_eq!(sum, 7);
    assert_eq!(product, 12);
}

The type Dual<T> is just a convenient alias for <T as Session>::Dual.

We use four different methods to communicate in the session:

• For Recv it’s recv and recv1, which need to be .await-ed.
• For Send it’s send and send1, which are not async.

The difference between recv and recv1, and between send and send1 is about the continuation. The versions ending with 1, recv1 and send1, can only be used if the continuation is (). Unlike their general versions, recv and send, they don’t return a continuation, and are not marked as #[must_use].**

The general recv and send can always be used instead of recv1 and send1, but then we have to deal with the returned (). The difference is just about convenience.

Branching

Now that we know how to move forward, it’s time to take a turn. Say we want to describe a communication between an ATM and a client interacting with its buttons. To make it simple, the interaction goes like this:

1. Client inserts a bank card.
2. If the card number is not valid, ATM rejects it and the session ends.
3. Otherwise, the ATM presents the client with two buttons:
   • Check balance: ATM shows the balance on the account and the session ends.
   • Withdraw cash: After pressing this button, the client enters the desired amount to withdraw.
     • If the amount is above the card’s balance, ATM rejects and the session ends.
     • Otherwise all is good, the ATM outputs the desired amount and the session ends, too.

To model such branching interaction, no additional dedicated types are provided by this crate. Instead, we make use of Rust’s native enums, and the ability to send and receive not only values, but session as well.

We start backwards, by modeling the interaction after an operation is selected:

use par::exchange::{Recv, Send};

struct Amount(i64);
struct Money(i64);
struct InsufficientFunds;

enum Operation {
    CheckBalance(Send<Amount>),
    Withdraw(Recv<Amount, Send<Result<Money, InsufficientFunds>>>),
}

The helper types – Amount, Money, and InsufficientFunds – are just to aid readability.

When branching, the first thing to decide is who is choosing, and who is offering a choice. In this case, the client is choosing from two options offered by the ATM. In other words, the client will send a selected Operation to the ATM, which receives it.

That’s why the sessions exchanged are described from the ATM’s point of view:

• Operation::CheckBalance proceeds to send the account’s balance to the client.
• Operation::Withdraw starts by receiving an amount requested by the client, then goes on to either send cash to the client, or reject due to insufficient funds.

Note, that there are already (kind of) two branching points above. One is between the two buttons, the second one is chosen by the ATM to accept or reject the requested amount. This second choice is only a “kind of” branching because no sessions are exchanged. But, an equivalent way to encode it would be to include a reception of the money on the client’s side: ...Result<Recv<Money>, InsufficientFunds>....

The beginning of the interaction then involves sending a selected Operation to the ATM, after validating the account’s number:

struct Account(String);
struct InvalidAccount;

type ATM = Send<Account, Recv<Result<Send<Operation>, InvalidAccount>>>;

Here the session is described from the client’s point of view. That’s arbitrary choice – the ATM’s point of view is simply the dual of the above:

use par::Dual;

type Client = Dual<ATM>;  // Recv<Account, Send<Result<Send<Operation>, InvalidAccount>>>

Picking a choice with Send::choose

Being able to model a session by freely using custom (Operation) or standard (Result) enums is certainly expressive, but how ergonomic is it to use? Turns out it can be quite ergonomic thanks to the choose method on Send.

Let’s implement a client that checks the balance on their account. Here’s a function that, given an account number, starts a Client session which does exactly that:

use par::runtimes::tokio::fork;

fn check_balance(number: String) -> Client {
    fork(|atm: ATM| async move {
        let atm = atm.send(Account(number.clone()));
        let Ok(atm) = atm.recv1().await else {
            return println!("Invalid account: {}", number);
        };
        let Amount(funds) = atm.choose(Operation::CheckBalance).recv1().await;
        println!("{} has {}", number, funds);
    })
}

After sending the account number and receiving a positive response from the ATM, the client is presented with a choice of the operation: check balance or withdraw money.

let Amount(funds) = atm.choose(Operation::CheckBalance).recv1().await;

At this point, the type of atm is Send<Operation>. But instead of calling send1, we choose Operation::CheckBalance.

Recall that the payload of Operation::CheckBalance is Send<Amount>. Send::choose returns the dual of that payload!

atm.choose(Operation::CheckBalance) // -> Recv<Amount>
    .recv1().await;

That’s why we can simply receive the response from the ATM afterwards.

What’s going on?

There are two manual ways to accomplish what choose does.

1. The inside way:

   atm.send1(Operation::CheckBalance(fork(|atm: Recv<Amount>| async move {
       let Amount(funds) = atm.recv1().await;
       println!("{} has {}", number, funds);
   })));

2. The outside way:

   let atm: Recv<Amount> = fork(|client: Send<Amount>| async move {
       atm.send1(Operation::CheckBalance(client));
   });
   let Amount(funds) = atm.recv1().await;
   println!("{} has {}", number, funds);

   Which can also be written with fork_sync!

   let atm = <Recv<Amount>>::fork_sync(|client: Send<Amount>| {
       atm.send1(Operation::CheckBalance(client))
   });
   let Amount(funds) = atm.recv1().await;
   println!("{} has {}", number, funds);

The inside way introduces nesting of the follow-up code which the outside way avoids. Since avoiding nesting is beneficial enough to warrant (validly) the whole async/await paradigm (replacing nested callbacks), the outside way is superior.

In short, all choose does is codify this outside form into a method. With any Enum and its Enum::Variant,

let session = Session::fork_sync(|dual| session.send1(Enum::Variant(dual)));

becomes

let session = session.choose(Enum::Variant);

Without any additional explanation, here’s a possible implementation of a client withdrawing money.

fn withdraw(number: String, Amount(requested): Amount) -> Client {
    fork(|atm: ATM| async move {
        let Ok(atm) = atm.send(Account(number.clone())).recv1().await else {
            return println!("Invalid account: {}", number);
        };
        let response = atm
            .choose(Operation::Withdraw)
            .send(Amount(requested))
            .recv1()
            .await;
        match response {
            Ok(Money(withdrawn)) => println!("{} withdrawn from {}", withdrawn, number),
            Err(InsufficientFunds) => println!(
                "{} has insufficient funds to withdraw {}",
                number, requested
            ),
        }
    })
}

Linking

In the last example, we defined dual sessions ATM and Client and implemented two behaviors for Client.

fn check_balance(number: String) -> Client { /* ... */ }
fn withdraw(number: String, Amount(requested): Amount) -> Client { /* ... */ }

For a full program, we’re missing the ATM’s side. We could just take the returned Clients and interact with them directly, but we can also construct an ATM separately. Then the question becomes how to wire them together.

To show that, we first need an ATM. For simplicity, we’ll be retrieving the accounts from a HashMap<String, Money>, without updating their balances upon withdrawals. Implementing that is left as a simple optional exercise for the reader.

Understanding the implementation below is not important for this section. All that’s important is to know the ATM looks in the provided accounts, and responds depending on the existence of a requested account and its balance.

use std::collections::HashMap;
use std::sync::Arc;

fn boot_atm(accounts: Arc<HashMap<String, Money>>) -> ATM {
    fork(|client: Client| async move {
        let (Account(number), client) = client.recv().await;
        let Some(&Money(funds)) = accounts.get(&number) else {
            return client.send1(Err(InvalidAccount));
        };
        match client.choose(Ok).recv1().await {
            Operation::CheckBalance(client) => client.send1(Amount(funds)),
            Operation::Withdraw(client) => {
                let (Amount(requested), client) = client.recv().await;
                if funds >= requested {
                    client.send1(Ok(Money(requested)));
                } else {
                    client.send1(Err(InsufficientFunds));
                }
            }
        }
    })
}

Let’s boot the ATM!

let accounts = Arc::new(HashMap::from([
    ("Alice".to_string(), Money(1000)),
    ("Bob".to_string(), Money(700)),
    ("Cyril".to_string(), Money(5500)),
]));

let atm = boot_atm(Arc::clone(&accounts));

Then start a Client session to withdraw some money from Cyril’s account.

let client = withdraw("Cyril".to_string(), Amount(2500));

The two dual sessions are now up and running. For wiring them together, the Session trait provides a useful method: Session::link!

Like send, it is non-blocking and non-async: it tells the two sessions to talk to each other and immediately proceeds, no .await required. Here’s what it looks like:

use par::Session;

atm.link(client);

And the whole program:

use par::Session;

#[tokio::main]
async fn main() {
    let accounts = Arc::new(HashMap::from([
        ("Alice".to_string(), Money(1000)),
        ("Bob".to_string(), Money(700)),
        ("Cyril".to_string(), Money(5500)),
    ]));

    let atm = boot_atm(Arc::clone(&accounts));
    let client = withdraw("Cyril".to_string(), Amount(2500));

    atm.link(client);

    // atm and client talk in the background, let them speak
    tokio::time::sleep(Duration::from_secs(1)).await;
}

A caveat of non-blocking functions like send or link is we need to add extra synchronization if we need to wait for the outcome. This usually isn’t a concern when a program is well intertwined – which it usually is. In this case, though, we need to wait for the two parties to finish interacting before exiting. We could insert an auxiliary Recv, but once again, for simplicity, we just sleep.

2500 withdrawn from Cyril

Linking is like a generalized calling of a function. It can be done on a single line, even if it’s a little verbose in Rust.

#[tokio::main]
async fn main() {
    let accounts = Arc::new(HashMap::from([
        ("Alice".to_string(), Money(1000)),
        ("Bob".to_string(), Money(700)),
        ("Cyril".to_string(), Money(5500)),
    ]));

    boot_atm(Arc::clone(&accounts)).link(check_balance("Alice".to_string()));
    boot_atm(Arc::clone(&accounts)).link(withdraw("Bob".to_string(), Amount(1000)));
    boot_atm(Arc::clone(&accounts)).link(withdraw("Dylan".to_string(), Amount(20)));

    tokio::time::sleep(Duration::from_secs(1)).await;
}

Bob has insufficient funds to withdraw 1000
Alice has 1000
Invalid account: Dylan

Recursion

In the realm of algebraic types, the basic building blocks of products and sums (structs and enums in Rust) explode into lists, maps, stacks, queues, and all kinds of other powerful data structures – via recursion. The same happens in the realm of session types: the basic building blocks of sequencing and branching make processing pipelines, worker pools, servers, game rule protocols, and so much more, when combined recursively.

Now that we’ve covered those basic building blocks, let’s take a look at how to create recursive session types to define complex and intricate communication protocols.

To start, we’ll stay with two-party protocols, but in the next section, we’ll also demonstrate how to construct sessions intertwining more than two parties (/ agents / processes / threads).

One of the most common tasks that involve repeating something an unknown number of times is processing a stream of incoming data. The queue module implements dedicated session types for this purpose. Before taking a look at it, though, we’ll implement such a protocol manually, to see how it’s done.

The task is: There is an incoming stream of integers. Add them all up and report the total sum back.

A recursive session protocol is exactly what we need to accomplish this. First it needs to branch on

1. receiving a number to add, or
2. finishing and reporting the total.

Then, in the first case, it needs to go back and repeat, until eventually reaching the second case.

Native recursion on types in Rust is all we need:

enum Counting {
    More(Recv<i64, Recv<Counting>>),
    Done(Send<i64>),
}

The enum defines two variants. On Counting::More, the counter receives a number and continues recursively. On Counting::Done, it’s required to send a number back: the total.

A couple of things to note:

• Counting itself is not a session type, just an enum. The two sides of the session will be using Recv<Counting> (from the counter’s point of view) and Send<Counting>. In more complicated use-cases, it’s recommended to set type aliases for the respective Recv<...> and Send<...> sides.
• No Box or Arc is required at the recursion point, Counting is Sized. That’s because the memory indirection needed for recursive types is already taken care of by the channels used in Recv/Send.

While the session type is recursive, its implementation doesn’t have to be! In fact, we’ll implement the counter using a loop and re-assigning:

fn start_counting() -> Send<Counting> {
    fork(|mut numbers: Recv<Counting>| async {
        let mut total = 0;
        loop {
            match numbers.recv1().await {
                Counting::More(number) => {
                    let (n, next) = number.recv().await;
                    total += n;
                    numbers = next;
                }
                Counting::Done(report) => break report.send1(total),
            }
        }
    })
}

The counter’s end-point of the session (numbers) is marked mut. In the case of Counting::More, after receiving the n to add and the next continuation of the session, we simply re-assign next into numbers. Note, that before the re-assignment, numbers has been moved-out-of in numbers.recv1().await – no dropping of a session happens.

Here’s how we can use the constructed counter to add up numbers between 1 and 5:

let sum = start_counting()
    .choose(Counting::More).send(1)
    .choose(Counting::More).send(2)
    .choose(Counting::More).send(3)
    .choose(Counting::More).send(4)
    .choose(Counting::More).send(5)
    .choose(Counting::Done).recv1().await;

assert_eq!(sum, 15);

The pattern of processing an incoming stream of data is ubiquitous enough to warrant standardization. That’s what the queue module is. Check out its documentation for more detail! It provides two ends of a stream processing queue – Dequeue and Enqueue – corresponding to the Recv<Counting> and Send<Counting>, respectively. Instead of Counting::More and Counting::Done, we can use Enqueue::push and Enqueue::close. On the processing side, Dequeue::pop, Dequeue::for_each, and Dequeue::fold are provided for ergonomic use.

Without further explanation, the counter can be rewritten this way:

type Numbers = Dequeue<i64, Send<i64>>;
type Counter = Dual<Numbers>;  // Enqueue<i64, Recv<i64>>

fn start_counting_with_queue() -> Counter {
    fork(|numbers: Numbers| async {
        let (total, report) = numbers
            .fold(0, |total, add| async move { total + add })
            .await;
        report.send1(total);
    })
}

And used elegantly:

let sum = start_counting_with_queue()
    .push(1)
    .push(2)
    .push(3)
    .push(4)
    .push(5)
    .close()
    .recv1()
    .await;

assert_eq!(sum, 15);

Multiple participants

All session types described so far had two sides to them: an ATM versus a single client; a calculator, or a counter versus a single user. That’s rarely sufficient for reasonable applications. A server will handle multiple clients, a game will have multiple players interacting in its world.

Those familiar with literature will know that our session types here are binary. They fundamentally have two sides of communication. The other side is always described by the dual. Research in session types goes on to introduce multi-party session types that explicitly model communication of more than two sides. While they have their advantages, they also introduce complexity and (disclaimer: personal impression) don’t seem to be ready for practical use.

What we are going to show here, however, is that no dedicated multi-party session types are needed to model and implement protocols involving arbitrary numbers of participants. And that is without any concessions to previously described guarantees like protocol adherence and deadlock freedom.

The key lies in how to juggle multiple session end-points concurrently.

To demonstrate, we’ll implement a very simple game of 3 players. For a general pattern of uniformly handling a dynamic number of participants, check out the server module.

The rules of the game are:

1. Each player independently picks one of two moves: UP or DOWN.
2. If everybody chooses the same move, it’s a draw and the game repeats.
3. Otherwise, one player must have chosen differently from the other two: that player wins!

In other words, the choices on the left map to the outcomes on the right:

• UP, DOWN, DOWN, or DOWN, UP, UP – first player wins.
• DOWN, UP, DOWN, or UP, DOWN, UP – second player wins.
• DOWN, DOWN, UP, or UP, UP, DOWN – third player wins.
• UP, UP, UP, or DOWN, DOWN, DOWN – draw.

Let’s model the game!

#[derive(Debug)]
enum Move {
    Up,
    Down,
}

enum Outcome {
    Win,
    Loss,
    Draw(Round),
}

type Round = Send<Move, Recv<Outcome>>;
type Player = Dual<Round>; // Recv<Move, Send<Outcome>>

The Round session is what the player sees. They are expected to send their move, then wait for an outcome of the round. Two outcomes are trivial: Win and Loss. The third one, Draw, recursively enters the next round, since no winner could be decided.

The full game involves three players entering the game and playing according to the above protocol until one of them wins.

#[derive(Debug)]
enum Winner {
    First,
    Second,
    Third,
}

type Game = Send<(Player, Player, Player), Recv<Winner>>;

We model it as a session that takes in three (running) Players, and reports the winner back. In between those, an implementation of Game must take care of the three Player sessions by making them play.

Here’s what we can do:

fn start_playing() -> Game {
    use {Move::*, Outcome::*, Winner::*};

    fork(|game: Dual<Game>| async {
        let ((mut player1, mut player2, mut player3), winner) = game.recv().await;

        loop {
            let (move1, outcome1) = player1.recv().await;
            let (move2, outcome2) = player2.recv().await;
            let (move3, outcome3) = player3.recv().await;

            tokio::time::sleep(Duration::from_secs(1)).await;
            println!("{:?} {:?} {:?}", move1, move2, move3);
            tokio::time::sleep(Duration::from_secs(1)).await;

            match (move1, move2, move3) {
                (Up, Down, Down) | (Down, Up, Up) => {
                    outcome1.send1(Win);
                    outcome2.send1(Loss);
                    outcome3.send1(Loss);
                    break winner.send1(First);
                }
                (Down, Up, Down) | (Up, Down, Up) => {
                    outcome1.send1(Loss);
                    outcome2.send1(Win);
                    outcome3.send1(Loss);
                    break winner.send1(Second);
                }
                (Down, Down, Up) | (Up, Up, Down) => {
                    outcome1.send1(Loss);
                    outcome2.send1(Loss);
                    outcome3.send1(Win);
                    break winner.send1(Third);
                }
                (Up, Up, Up) | (Down, Down, Down) => {
                    player1 = outcome1.choose(Draw);
                    player2 = outcome2.choose(Draw);
                    player3 = outcome3.choose(Draw);
                    println!("Draw...");
                }
            }
        }
    })
}

Let’s break it down!

At first, we take in the three Player session.

let ((mut player1, mut player2, mut player3), winner) = game.recv().await;

All three of them are now in scope at the same time. This is the key to handling multiple participants. Having access to all, the Game can coordinate them according to one another. In this context it’s only to decide the outcome and proceed with the game – in other contexts, more complicated mutual interactions can be implemented.

The rest of the code is concerned with deciding the outcome and communicating it.

• In the case of a winner, the Player sessions are terminated by either a Win or a Loss, and the pending winner response is completed.

• Otherwise in the case of a draw, the winner channel is left pending, and draws are communicated to the players, which makes them stay to play another round according to the Round protocol.

Let’s have some fun playing!

fn random_player() -> Player {
    fork(|mut round: Round| async move {
        while let Outcome::Draw(next_round) = round.send(random_move()).recv1().await {
            round = next_round;
        }
    })
}

fn random_move() -> Move {
    if fastrand::bool() {
        Move::Up
    } else {
        Move::Down
    }
}

#[tokio::main]
async fn main() {
    for _ in 0..10 {
        let winner = start_playing()
            .send((random_player(), random_player(), random_player()))
            .recv1()
            .await;
        println!("{:?}!\n", winner);
    }
}

Up Up Down
Third!

Down Up Up
First!

Down Down Down
Draw...
Up Down Up
Second!

Down Up Down
Second!

Modules

exchange

Exchange a single value (possibly another session), then proceed according to a continuation session. The two sides, receiving and sending, are Recv and Send, respectively.

queue

Transmit any number of values of the same type, then (after transmitting all) proceed according to a continuation session. The two sides, receiving and sending, are Dequeue and Enqueue, respectively.

runtimes

Asynchronous forking functions for different async runtimes.

server

Handle a dynamic number of clients with interaction protocols specified by session types. Start a Server, initiate the connection protocol via a Proxy, and obtain an active Connection to resume the interaction later.

Traits

Session

Type Aliases

Dual