Skip to content
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

spawn_fn_with_addr is not really ergonomic way to create circular actor dependencies #9

Open
skywhale opened this issue Feb 19, 2021 · 2 comments
Labels
API Relates to public API surface

Comments

@skywhale
Copy link
Member

No description provided.

@strohel strohel added the API Relates to public API surface label Feb 19, 2021
@strohel
Copy link
Member

strohel commented Feb 21, 2021

I deliberately used circular actor system in the echo example to witness this. It feels less natural than spawning linear actors, but not horrible. It is impossible to "forget about this" as it is otherwise impossible to orchestrate the actors within the type system boundaries.

Only possible mitigation that comes to my mind is to somehow separate the "actor creation phase" from the "actor connecting phase". Maybe by some explicit concept of "connecting" and/or "pads" (output sockets). But that doesn't sound compelling to me. Perhaps spawn_fn_with_addr() is a reasonable price to pay for simplicity of the "normal" case?

I'll stick one possibly related idea to #10 - did not end up being helpful here.

@bschwind
Copy link
Member

One thing I had experimented with in the past was storing actor addresses in a "registry" upfront, and then actors could request an address of a certain actor type via a generic function on System. The downside is you can only have one instantiation of each actor, and the code looked a little clumsy in the "normal" case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Relates to public API surface
Projects
None yet
Development

No branches or pull requests

3 participants