@sleipnir I know that one is a framework and the other is more of a small helper.
I just don’t understand why we need a npm dependency which installs a python dependency which then performs a task, when we instead could just use a rust dependency which does the same thing.
11 replies
Take a look how I have reorgonized https://github.com/actors-rs/actors.rs. mkdocs and frontpage will require npm.
And I have added use of https://github.com/budziq/rust-skeptic to make sure examples in documentation in good shape.
npm is not really needed but you can take benefit of "scripts" in package.json, that is supported by many IDE, like CLion or vs code.
riker-rs/riker#108
I think all clippy warnings should be fixed, I have fixed myself most of them during several days on actors.rs
I see @hardliner66 is #2 https://github.com/riker-rs/riker/graphs/contributors
No, but giving people merge rights without proper thought is.
@leenozara please invite someone else to have merge rights https://github.com/orgs/riker-rs/people
No, but giving people merge rights without proper thought is.
@leenozara please invite someone else to have merge rights https://github.com/orgs/riker-rs/people
Here is example of very good proposal I have contributed a little, 69 people asked and it still sits during 5 years. Eclipse foundation is very big community. My point that is always good to invite people to contibute, the lack of interested people in improvements will result into such proposals sitting during years!
https://bugs.eclipse.org/bugs/show_bug.cgi?id=477475
riker has been updated to version 0.4.1. This includes optimizing by removal of unnecessary boxing and cloning, replacing mutex locks with better concurrency alternatives, and an improvement to log guard handling.
Special thanks to @hardliner66 , @xacrimon and @mrjoe7.
In addition to this new version there have been important updates to code, project structure and build process, as well as code review and discussion. Thanks to @igalic, @olexiyb, @aav and others for all the input.
[dependencies]
riker = "0.4.1"
@anacrolix Currently there is no built-in way to wait for completion until riker-rs/riker#58 is implemented.
In the meantime there are some workarounds you can use:
1) Use an external synchronization primitive to signal completion (e.g.: a channel, a semaphore, etc...)
2) Wait until the user root has no child actors left
Use number 1 if you have some actors performing some tasks and an actor which collects the results, and know at start how many results you will get.
Because in this case the actor which collects the results can send a message on a channel once it has all the results.
Otherwise you could make sure that every actor stops once it has finished it's work and wait for the child count of the root actor to reach 0.
But for this to work you have to use Strategy::Stop as supervision strategy and all direct children of the user root must live until your program has finished all it's work.
The problem with both is, that they are very brittle. Especially number 2 can break in strange ways if you aren't extremely carefull.
.await an response.
@hardliner66 how would I do this one:
Otherwise you could make sure that every actor stops once it has finished it's work and wait for the child count of the root actor to reach 0.
But for this to work you have to use Strategy::Stop as supervision strategy and all direct children of the user root must live until your program has finished all it's work.
That's the behaviour I want.
@AdriaanPrinsloo
There's two main approaches. The first I would recommend would be to handle your ZMQ IO separately from Riker. You could use Tokio for this or any other IO optimized implementation. When you receive your Request 0mq message you can offload the processing of that to Riker by sending to the respective actor. Your ZMQ queue can continue to handle other Requests. The actor handling the message can choose to send a Response. Typically you could either send a ZMQ reference along with your original message, or you could include such a reference when you create/start the actor. You end up with two "reams", ZMQ and Riker, and no blocking would be necessary.
The other approach would be to handle the ZMQ orchestration and IO inside of Riker. To do this in a non-blocking manner you'd typically use an actor that contains the ZMQ socket and instead of blocking, schedule a message (Check, or Tick, for example) 50ms at the end of recv to be send to myself. Every Tick you check if the ZMQ socket has data and if so get the message. A simple implementation is easy, but if you want to handle a lot of IO then there are patterns you can use to optimize this. The only time you want that Tick message scheduled is when there is no more ZQM messages.
Ideally, you don't ever want to block. Also note that Ask is a future and will require you to block (await) to get the result to the current thread - therefore it's better suited to futures composition where you have a chain of futures working to completion.