https://github.com/actors-rs/actors.rs
folder structure.
I have moved example, frontpage and mkdocs to be part of the same repo.
This way you can propose some change and document at the same time and examples will be kept up to date as well.
I also utilize standard github pages, so you do not need to pay for hosting
https://actors-rs.github.io/
I will be glad to contribute to riker.
Plus I have added support of https://github.com/pre-commit/pre-commit to enforce the change before commit.
especially this one riker-rs/riker#84
cheeky
CQRS is in a second repository: https://github.com/riker-rs/riker-cqrs
Hi all, Riker 0.4.0 has been published. This is a breaking change that introduces a much improved syntax to creating actors. A special thanks to @hardliner66 for this excellent contribution.
I've updated the first page on the riker document site to use this new syntax and expand on the different ways creation in general can be done. I will update the rest of the documentation asap but I wanted to get this new version published today at the latest. riker-patterns will also be updated asap.
Thank you all for your PRs and issues!
[dependencies]
riker = "0.4.0"
riker-patterns has been updated. [dependencies]
riker-patterns = "0.4.0"
yeah that's a complex question to answer. The idea of 'backpressure' comes into play here. And your question is the right one I think: Should backpressure be a part of riker, and if so is it a component of actors or something else? There are advantages of having unbounded mailboxes. A lot of this comes back to what an actor is, what it represents. In Erlang for example an actor is the unit for concurrency. For Akka, actors are a means to manage concurrency + state, and the unit for concurrency is just a stream.
In Rust we already have async and backpressure so I'm not sure if that should be extended to Riker actors. By that I literally mean I don't know, not that my opinion is that it shouldn't be extended. I do think at the very least we should be providing best practices for this and clearly communicating what riker does and does not do, which isn't the case currently. I also think that it's important not to position Riker as an alternative to the work being done on async/futures because clearly the minds behind that are vastly better suited for the problems they're trying to solve. In that sense Riker is closer to Akka in that it is building on top of the language's standard concurrency to solve different problems.
I'm sure you get all of this already but it's a common question so I'm providing an answer for others to see also. So my opinion is: At minimum we need to provide standard guidance on the problem of unbounded messages and how to implement some backpressure. At ideal, we should have something configurable that 'just works' without the deadlocks you see.
Option or defaults on your data type if you're storing any config values. In your case would these work?/// Invoked when an actor is being started by the system.
///
/// Any initialization inherent to the actor's role should be
/// performed here.
///
/// Panics in `pre_start` do not invoke the
/// supervision strategy and the actor will be terminated.
fn pre_start(&mut self, ctx: &Context<Self::Msg>) {}
/// Invoked after an actor has started.
///
/// Any post initialization can be performed here, such as writing
/// to a log file, emmitting metrics.
///
/// Panics in `post_start` follow the supervision strategy.
fn post_start(&mut self, ctx: &Context<Self::Msg>) {}