#actor #runtime #async #erlang #pony

stakker

A lightweight low-level single-threaded actor runtime

13 releases

0.2.4 May 14, 2021
0.2.1 Feb 25, 2021
0.2.0 Nov 8, 2020
0.1.2 Jul 16, 2020
0.0.2 Mar 4, 2020

#71 in Asynchronous

Download history 63/week @ 2021-04-03 48/week @ 2021-04-10 64/week @ 2021-04-17 49/week @ 2021-04-24 42/week @ 2021-05-01 33/week @ 2021-05-08 61/week @ 2021-05-15 26/week @ 2021-05-22 30/week @ 2021-05-29 40/week @ 2021-06-05 26/week @ 2021-06-12 30/week @ 2021-06-19 27/week @ 2021-06-26 25/week @ 2021-07-03 26/week @ 2021-07-10 56/week @ 2021-07-17

206 downloads per month
Used in 4 crates

MIT/Apache

375KB
6.5K SLoC

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.

Dependencies

~290KB