Dema's Quartz 🔮

Radon Runtime Implementation

7 min read

  • Runtime core technology

  • Wasm engine

  • Atom compilation

  • Atom execution

    • Threading
    • Daemons and shit

  • FFI details

    • Passing data
    • Compilation steps

  • Runtime function technology and implementation

  • Messaging

    • Mbox

  • Interrupts and Futures implementation

  • Remote communication

    • Network stack
    • Communication strategy, pools multiplexing and serialization

  • Local storage KV

  • Naming

  • Deployment

  • REST integration (?)

Inventory

  • Raw components
    • WASM engine
    • Storage engine
    • Network protocol
    • Naming protocol
    • Frontend
    • Deployer
  • Composite components
    • Atom compiler and cache cache
    • Atom registry/scheduler
    • MessageBox
    • Interrupt/Future system
    • FFI

This section describes the key technological details of the current runtime implementation.

The implementation we are presenting serves as a showcase of what can be achieved with the paradigm we are presenting. The runtime implementation is modular and allows for easy replacement of parts of the technological stack, this reflects the desire for reconfigurability we expressed in the rest of the paper.

It must be noted too, that even though this implementation of the runtime is itself modular and reconfigurable, it is not strictly tied to the radon specification. As a matter of fact, future work could extend the runtime or write an entirely new version without requiring any modification to the user code (provided that the atoms and the new runtime implementation correctly implement the specification).

Move down ^

Divison In this section, we will refer to the current Radon runtime implementation as \R0. \R0 is implemented in Rust and at its core it connects the following components: a WebAssembly engine, an embedded persistent storage solution, a networked messaging implementation, a name resolution service and a frontend that interfaces with external events.

Form This component is compiled to a single binary executable (with the possibility of targeting different processor architectures), the binary is then distributed to multiple machines using a deployment component (called formula) that parses a configuration containing the available machines with their associated capabilities (expressed in the form of tags) and the set of atom configurations to be deployed on the distributed cluster. Formula reads the configuration, bundles all the WASM modules corresponding to the atoms present in the deployment configuration and ship them together with the \R0 binary to all machines using the SSH protocol.

Deployment Also in this case it must be noted that the formula component is just a proof of concept implementation of a deployment system, however it is not coupled to the implementation of \R0 and future work could integrate the runtime with already established deployment tools such as Kubernetes, Ansible or Terraform. As a matter of fact, \R0 is designed to be agnostic to architectural paradigms and to be adaptable to manual and automatic deployment strategies on different architectural topologies, including monoliths, homogeneous and heterogeneous clusters, serverless and edge (and any combination of them). To achieve this, the binary can be compiled with statically bundled libraries and only requires for the its configuration to be supplied via environment variables or toml configuration files.

Internal components/contributions Alongside the previously mentioned fundamental blocks of \R0, we implemented a set of internal components that are used to connect and coordinate them. In particular, we build on top of the WASM engine and develop a system for compiling, caching and indexing the atom configurations, we develop a concurrent message box for efficient local messaging, a network protocol agnostic reordering buffer for FIFO messaging using multiple channels, we implement the routing mechanism for interrupts and futures with the corresponding wasm-side library components to register the associated callbacks.

Nota: ho fatto una panoramica di tutti i componenti che direi che sono relevant contributions (circa), poi qua dipende da quanto vogliamo andare nel dettaglio, forse sceglierei magari un subset degli internals che può essere più interessante, ad esempio la parte di interrupt management e del messagebox

Execution model and scheduling Going in the details on how an atom is executed, we highlight some of the characteristics of the execution model. The current implementation relies on OS threads as the execution context for atoms (spawning a dedicated thread for daemons and using a thread pool for reactive atoms). The life cycle of an atom starts with the creation of a Webassembly Store and Instance and then with a call to its invoke function. The invoke function is an exported WASM function, the exact process of calling an exported function differs from one WASM engine to another, however, some key characteristics are shared (add figure showing the stack): when we call the function, we create a call stack that is the state of the function execution within the WebAssembly context, this stack sits on top of the call stack of the runtime thread that called the invoke function. One key intuition is that this is not a one-way process, as a matter of fact, from the WASM code we can call an imported function and go back to executing the runtime code. Other than using this process to provide the efficient implementation of the runtime functions as compiled native code, we use this mechanism to enforce a mechanism of implicit preemption on blocking operations. To enable this, we must perform an additional step, in the execution context of the runtime functions we include a handle to the store of the WebAssembly instance that invoked it, this way we allow access to the exported functions. Thanks to this structure, we can call other exported functions before yielding back control to the invoke function. We use this mechanism to implement futures and interrupts: the implementation of blocking runtime functions can see that an interrupt or a future is in need of processing and it can execute them […]

Execution flow Stack and execution technology Execution context

Feedback: threading discussion, atom execution flow, messaging details, KV Store

Naming

Naming is one of the most critical aspects of a distributed application, entities must be able to send messages to entities they know and discover ones they do not know. In order to answer to the different requirements of most distributed programming paradigms we propose a two layer, scoped naming system with wildcard resolution.

As a minimal set of features, the naming implementation must provide

  1. Each active runtime in the deployment must have a unique flat name
  2. Each atom configuration loaded in a runtime must have a locally unique flat name
  3. The unique global name for an atom is the concatenation of the runtime name and the atom name separated by a delimiter
  4. By querying the atom name without knowing the runtime name, we can resolve to the global name of an atom with that atom name (any, if it exists)
  5. Each atom can have a single name, but can have many scoped aliases
  6. An alias is in the form of a key, value pair, both strings, where the key is the scope and the value is the alias
  7. In addition to the exact lookup of a name, one can lookup any or all atoms that have a name that matches a pattern. This pattern uses a wildcard character to denote that part of the name can contain any value (Note: currently it is an actual regex and it should be a regex of some form!)
  8. Any and all lookup can be performed both on the atom name and on the scoped aliases

With this set of operations, we can implement different patterns of messaging and discovery: like in an actor system, we can find an actor knowing its exact name, but not where it is situated; we can use aliases as a way to express the capabilities of an atom and find any atom that has some characteristic, in an object-oriented-like pattern; we can use aliases to represent a subscription to a topic of a publisher subscriber system, then using all queries we get all the sub.

Our current implementation uses an extended version of the wildcard matching, allowing for regular expressions of bounded complexity (rust regex crate) (Note: we should maybe discuss what is the level of expressiveness we want to mandate in the model).

From an atom’s perspective the physical implementation of the naming system is hidden, the naming in \R0 follows a leader-follower architecture, however different architectures (hierarchical, multi-leaded, peer-to-peer) could be added without requiring changes in the atom interface.

Graph View