Feature request: utility to call the same actor with multiple messages about ractor

[msparkles]

Got it :) We might work on it when we have time and motivation!

[slawlor]

Couldn't you use the existing multi_call and give an array of the same actor? Wouldn't that achieve the same result here?

I think there's definitely a use-case for having a MultiReplyPort or something, so instead of a single result, you could get a stream of results for example. But normally that's not something present in Erlang's OTP, and we'd probably build a different pattern for it when needed. As an example, send a cast with an argument of the reply actor, and then the caller sends N messages back to the caller. But it won't block the same way as an RPC.

[msparkles]

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.

[msparkles]

And also, we're not sure if multi_call would help here, since the messages are different.

[slawlor]

How would you have a mpsc reply port if the input messages are different, therefore likely resulting in different reply types? Unless you have each message have the same return type, which then is quite flaky to provide something at a framework level, I don't see how you could make this work.

We could add a multiple-reply port, but I don't see a strong reason to do it yet (personally).

[msparkles]

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.

[msparkles]

The messages also have the same enum kind, they're all the same kind just different parameters.

[slawlor]

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.

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 ractor_cluster I think, so i'm hesitant to do it. If you however wish to put up a PR of what it might look like I'm open to considering it! Thanks :)