Crate bastion[][src]

Expand description

Bastion: Fault-tolerant Runtime for Rust applications

Bastion is a highly-available, fault-tolerant runtime system with dynamic dispatch oriented lightweight process model. It supplies actor model like concurrency with primitives called lightproc and utilize all the system resources efficiently with at-most-once message delivery guarantee.

To have a quick start please head to: Bastion System Documentation.


  • Message-based communication makes this project a lean mesh of actor system.
    • Without web servers, weird shenanigans, forced trait implementations, and static dispatch.
  • Runtime fault-tolerance makes it a good candidate for distributed systems.
    • If you want the smell of Erlang and the powerful aspects of Rust. That’s it!
  • Completely asynchronous runtime with NUMA-aware and cache-affine SMP executor.
    • Exploiting hardware locality wherever it is possible. It is designed for servers.
  • Supervision system makes it easy to manage lifecycles.
    • Kill your application in certain condition or restart you subprocesses whenever a certain condition is met.
  • Automatic member discovery, cluster formation and custom message passing between cluster members.
    • Using zeroconf or not, launch your bastion cluster from everywhere, with a single actor block.
  • Proactive IO system which doesn’t depend on anything other than futures.
    • Bastion’s proactive IO has scatter/gather operations, io_uring support and much more…


  • At most once delivery for all the messages.
  • Completely asynchronous system design.
  • Asynchronous program boundaries with fort.
  • Dynamic supervision of supervisors (adding a subtree later during the execution)
  • Lifecycle management both at futures and lightproc layers.
  • Faster middleware development.
  • Above all “fault-tolerance”.

Why Bastion?

If one of the questions below is answered with yes, then Bastion is just for you:

  • Do I want proactive IO?
  • Do I need fault-tolerance in my project?
  • Do I need to write resilient middleware/s?
  • I shouldn’t need a webserver to run an actor system, right?
  • Do I want to make my existing code unbreakable?
  • Do I need an executor which is using system resources efficiently?
  • Do I have some trust issues with orchestration systems?
  • Do I want to implement my own application lifecycle?


Allows users to communicate with Child through the mailboxes.

Children are a group of child supervised under a supervisor

Allows users to communicate with children through the mailboxes.

A context allows a child’s future to access its received messages, parent and supervisor.

Special module that allows users to interact and communicate with a group of actors through the dispatchers that holds information about actors grouped together.


Cluster formation and distributed actor instantiation

Distributor is a mechanism that allows you to send messages to children.

A envelope wraps messages and signs them to help user identify message senders and instruct Bastion how to send messages back to them

Describes the error types that may happen within bastion. Given Bastion has a let it crash strategy, most error aren’t noticeable. A ReceiveError may however be raised when calling try_recv() or try_recv_timeout() More errors may happen in the future.

A module that exposes the functions used under the hoods from bastions macros: spawn!, run! and blocking!.

IO subsystem for Bastion

Dynamic dispatch oriented messaging system

A path represents a message sender’s semantics and later will be used to route messages to them

Prelude of Bastion

Special kind of structs for resizable actor groups in runtime.

Supervisors enable users to supervise a subtree of children or other supervisor trees under themselves.


Answers to a given message, with the given answer.

Spawns a blocking task, which will run on the blocking thread pool, and returns the handle.

This macro creates a new children group with the given amount of worker callbacks, and a closure that will be executed when a message is received.

Matches a Msg (as returned by BastionContext::recv or BastionContext::try_recv) with different types.

This macro blocks the current thread until passed future is resolved with an output (including the panic).

Spawn a given future onto the executor from the global level.

This macro creates a new supervisor with the given strategy and the given callbacks. Children can be specified by using the children / child macro. You can provide as many children groups as you want. Supervised supervisors are currently not yet supported.


A struct allowing to access the system’s API to initialize it, start, stop and kill it and to create new supervisors and top-level children groups.

A set of methods that will get called at different states of a Supervisor or Children life.

The configuration that should be used to initialize the system using Bastion::init_with.