Crates.io | steelmill |
lib.rs | steelmill |
version | 0.0.2 |
source | src |
created_at | 2023-12-18 21:41:18.958359 |
updated_at | 2024-04-26 00:57:37.023154 |
description | A resource manager (dependency injector / factory) designed for distributed systems and simulation testing |
homepage | |
repository | https://github.com/crystalcld/steelmill/ |
max_upload_size | |
id | 1073713 |
size | 90,393 |
This library makes it easy to manage multiple long-running services (called Daemon
s) within a single Rust process. It targets asynchronous, multi-threaded runtimes, and is lock-free.
Daemons
are managed by a hierarchy of Factory
objects. Factories use Daemon
instances from their parents when appropriate, allowing them to share states. There are two primary reasons to create children factories:
Factory
manages Daemons
that are logically running on different machines, even though the entire setup is in a single operating system process.In addition to the base library, this crate contains helpers for unit testing, and an example application that lets you choose which Daemons
to instantiate by passing in command line arguments.
Zero-cost simulation testing of asynchronous rust code is more challenging than we would like. On the one hand, we'd like to be able to simulate performance-critical data-path APIs, implying that they should be invoked via some sort of interface. On the other hand, as of this writing, Rust does not support async traits, and the workaround (the async_trait
crate) adds a memory allocation to each invocation of an async function!
As a workaround, we currently suggest applications use cargo feature flags to either compile their application for runtime usage, or for simulation testing. Using conditional compilation to provide mutually-exclusive features goes against cargo's design, so we have to do strange things to trick it into behaving as desired. The sample application shows how to do it, but we hope to switch to a different approach once async traits have stablized.