| Crates.io | steelmill |
| lib.rs | steelmill |
| version | 0.0.2 |
| created_at | 2023-12-18 21:41:18.958359+00 |
| updated_at | 2024-04-26 00:57:37.023154+00 |
| 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 Daemons) 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.