type Msg = ValidationMsg;, but my response is a different struct
Propsuntil I decided to just implement
ActorProducermyself along with an
impl Into<BoxActorProd<MyActor>> for MyActorConfiguration. I feel like there might be some leftovers from a time when lifetime annotations in Rust were much harder than they are now. Because from what I gather is that
ActorSystem::actor_of_propsshould be able to take ownership of the passed-in
Propsat which point the lifetime shouldn't be a problem anymore.
Timer.schedule- I set up a timer for 10 milliseconds and then the thread owning the ActorSystem goes to sleep for a second. Afterwards, I shut down the system and only 18 messages have been received in the meantime. I know that delivery cannot be guaranteed. Increasing the interval to 100ms yields 9 messages in 1 second which is more or less expected. 80ms yields 9 messages, too. 20 ms yields 16 messages now. All in all I'd have expected it to be able to have much shorter timers... The same happens if I use
Timer.schedule_onceand re-schedule a new message after receiving the first one. What stands out is the fact that the number of messages seems constant during execution and dependent on the interval. But it doesn't seem to change depending on CPU load of the overall host system, so I have a feeling it's not related to actual runtime constraints but some weird bug, maybe from me mis-using the API. Will try to come up with a SSCCE...
hi @all. I just wanted to say that I will move away from riker (I'm not the maintainer, but I was on the way to becoming one before the hiatus). I commented my reasoning here: https://github.com/riker-rs/riker/issues/102#issuecomment-973843649
Key points for new users: If your use case is too complex or you're not willing to fix internals yourself, you should probably check out different actor systems. Maybe someone of you is willing to fork the project. @milgner Maybe you or the company you work for can take on the task of forking, which could be a benefit for all.
If you have any questions, feel free to ask, I'm still gonna be around a bit.
I'm the maintainer of Riker and I've replied here https://github.com/riker-rs/riker/issues/102#issuecomment-973843649 and posting it here below so it's easily found for everyone:
I wish I could be active in Riker project management and development. Maybe I can come back to the project in the future but there's no guarantees. I tried to establish shared ownership and responsibility with the community but it seems I wasn't able to make a compelling enough reason to make it happen. I've resisted doing quick PR reviews just to get code merged because I would prefer to have Riker remain committed to the original design principles, something between Akka and Erlang actors.
At this time, if I were to commit myself to giving Riker the time, the love it deserves it would impact other businesses, the work and jobs of other people. As much as I'd like to, I can't alone manage Riker for now. I will say though that I believe more than ever that an actor system development framework for Rust is ideal. We're seeing continued growth of Rust - it's expanding to be applied across many use cases, moving further away from the metal, on to blockchains (Solana) and more. As robotics becomes less about the hardware and more about the software and systems, the more a framework like Riker is needed.
If anyone has ideas about how to move the project forward, github, website, etc., I'd be more than happy to hear.
@hardliner66 has mentioned another actor system project for Rust called Bastion. I've looked at this and can happily say that the fundamental design of this appears to be sound. If you're looking for an actor system you might want to see if Bastion is more actively developed and explore that project for your needs.