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

Let Actors specify their default Addr capacities #70

Closed
strohel opened this issue Jul 19, 2022 · 0 comments · Fixed by #66
Closed

Let Actors specify their default Addr capacities #70

strohel opened this issue Jul 19, 2022 · 0 comments · Fixed by #66
Assignees

Comments

@strohel
Copy link
Member

strohel commented Jul 19, 2022

Currently, if a user wants to create an actor with non-default (normal and/or high-priority) inbox capacities, they need to either create their addr first using Addr::with_capacity() or spawn them using system.prepare[_fn]().with_capacity().

However, the actors themselves often have enough information to determine their best (or at least good default) inbox capacities, so let's allow them doing so! This has a potential to noticeably simplify "actor system setup" codebase sections.

Addr already has actor generic type parameter, so it can access static methods and constants defined on it in its constructor.

Implementation-wise this would be about adding either an associated constant to Actor trait to determine default capacity (if Rust allows having defaults for associated constants), or a static method (without &self) to the Actor trait with default implementation. In both cases we likely don't want to add any more mandatory items that Actors need to implement. Change impl Default for Addr to use these method(s)/constant(s).

Another thing left to bikeshed is whether this should be a single constant/method returning Capacity, or 2 separate methods/constants for normal, high-prio capacities returning usize. Notice the DEFAULT_CHANNEL_CAPACITY constant is not currently public.

CC @bschwind @skywhale @PabloMansanet.

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

Successfully merging a pull request may close this issue.

2 participants