stakker

Crates.iostakker
lib.rsstakker
version0.2.11
sourcesrc
created_at2020-01-23 19:37:53.773798
updated_at2024-05-28 20:32:20.220611
descriptionA lightweight low-level single-threaded actor runtime
homepagehttps://uazu.github.io/stakker
repositoryhttps://github.com/uazu/stakker
max_upload_size
id201335
size454,474
Jim Peters (uazu)

documentation

https://docs.rs/stakker

README

A lightweight low-level single-threaded actor runtime

license:MIT/Apache-2.0 github:uazu/stakker crates.io:stakker docs.rs:stakker uazu.github.io:stakker

Stakker is designed to be layered on top of whatever event loop the user prefers to use. It aims to take maximum advantage of Rust's compile-time checks and optimisations.

Documentation

See the crate documentation and the Stakker Guide and Design Notes

License

This project is licensed under either the Apache License version 2 or the MIT license, at your option. (See LICENSE-APACHE and LICENSE-MIT).

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Maintenance approach

You're very welcome to try to break this code! I intend to conform to Rust safety conventions, including on internal interfaces. Any unsound behaviour that can be shown to exist will be treated as a serious bug, and I will endeavour to find a solution as soon as reasonably possible.

I reserve the right to (metaphorically) go off to a mountain-top cave to consider issues in depth, to make the right decision without being rushed.

Most of the design decisions in this software have had a lot of consideration, with many different approaches tried and discarded before arriving at the current solution. The current implementations have been rewritten and refactored and minimised to get to the current state. So I'd ask that any requests for changes to how things are done be accompanied by some reasonably in-depth justification, such as example use-cases that require the change, or some other discussion of why that change would be a good one. I prefer to keep the code tight, so I might need to refactor PRs, or reimplement them a different way.

Commit count: 30

cargo fmt