Some immature thoughts on inter-actor communication

[hanekoo]

Thank you very much for your contributions to this project. I have already used it in practical projects, and the asynchronous features have been very helpful.

Here are some thoughts I had while using it in real projects:

1. Similar to on_link_died, perhaps a hook like on_link_start could be provided to know whether other actors have started successfully.

2. Alternatively, a broadcasting feature like BroadcastMailbox (which unfortunately has been closed) could be implemented, allowing other actors to notify the parent actor.

3. I know that PubSub<M> currently exists, but it only supports a single message type. I hope to see something similar to actix_broker that provides convenient multi-message type publishing/subscribing through actix_broker::BrokerSubscribe / actix_broker::BrokerIssue, along with enhancements for global (system) messages or group (arbiter) messages.

Looking forward to more distributed features as well.

[tqwewe]

Thanks for your feedback, very valuable!

1. on_link_start is a very nice idea I haven't thought of. Did you have a particular use case for this in your experience with kameo?

2. I'd still like to explore the possibility of using a broadcast mailbox, however I couldn't find a nice API design I was happy with. But its something I'm open to for suggestions and ideas

3. Improving the usage of PubSub would be great, and having it be a single message type is a little limiting. Thanks for pointing out actix broker, I haven't seen that one before

All great suggestions, and I'll try exploring these when I get more time, thank you :)

[marcaddeo]

Something tangentially related I've been thinking about; would it be possible for actors to know about their parent, child, sibling actor refs when actors are supervised/linked? Is that even a good idea?

When I first started using Kameo, that's how I expected the parent/child supervision to behave (I'm not sure whether or not this is how Erlang/OTP function) but ended up realizing I need to pass the refs manually between the actors that need to communicate with each other.

[tqwewe]

Would an on_linked or on_link_start hook added to the Actor trait solve this @marcaddeo?

[hanekoo]

Something tangentially related I've been thinking about; would it be possible for actors to know about their parent, child, sibling actor refs when actors are supervised/linked? Is that even a good idea?

When I first started using Kameo, that's how I expected the parent/child supervision to behave (I'm not sure whether or not this is how Erlang/OTP function) but ended up realizing I need to pass the refs manually between the actors that need to communicate with each other.

Yes, I've encountered this too.

• Sometimes it's uncertain whether an actor reference is needed within a struct.
• It can also be intrusive to the struct.

[hanekoo]

1. on_link_start is a very nice idea I haven't thought of. Did you have a particular use case for this in your experience with kameo?on_link_start

This mainly depends on the application’s design requirements, especially in applications where actors have strong dependencies on each other.

For example, separating an actor that initializes a TcpStream (init_actor) from the one that processes the TcpStream (process_actor), but with dependencies between them. process_actor depends on whether init_actor starts successfully (though this example may be a bit of a stretch).

It’s a bit like depends_on in Docker Compose, right?

[marcaddeo]

Would an on_linked or on_link_start hook added to the Actor trait solve this @marcaddeo?

Yeah, if that hook contained the actor ref and some sort of "LinkKind::Child" marker to know what kind of link it is. I think that would probably work great.