New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: utility to call the same actor with multiple messages #111
Comments
Couldn't you use the existing I think there's definitely a use-case for having a |
We transitioned from Riker-rs to ractor just now. We made this code because in riker, calling the actor a bunch of times and getting the results (internally via a lot of Oneshot's, just like ractor) was slow, so we made one that utilizes a mpsc channel to make it faster. (And it did improve efficiency there!) We're not certain that this approach would necessarily be faster in ractor, but generally mpsc seems to fit better than creating a lot of oneshot's for when you have multiple messages with each a response. Maybe we could make a benchmark, hm. |
And also, we're not sure if |
How would you have a We could add a multiple-reply port, but I don't see a strong reason to do it yet (personally). |
The messages are different as in they each have different parameters, specifically different parameters in an Enum. The replies are the same way, different parameters in the same type as other replies. We meant that the message values are different, not the types, sorry for the confusion. |
The messages also have the same enum kind, they're all the same kind just different parameters. |
From my point of view, this would be the only reason to add what you're requesting here. It would require a decent amount of support changes in the proc macros of |
Got it :) We might work on it when we have time and motivation! |
We have written up a (crude) utility function to send multiple messages to the same actor and receive the response with a mpsc channel.
This is mainly to minimize overhead.
Is it possible to include such feature in ractor?
Here's my implementation. One big flaw is that this requires making another message type for MpscSender instead of using RpcReplyPort
The text was updated successfully, but these errors were encountered: