-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add Dispatchers #639
Add Dispatchers #639
Conversation
… to create; updated router example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not exactly sure what I'm doing w/ SINGLETON_ID here, and I don't replicate it for Private
discoverers.
It should be neither or both.
@jstarry It looks to me like the CI is acting funky (although because of the breaking change, I still probably broke another example, but its failing for what appears to be unrelated reasons) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely understand the motivation for this, seems like a nice ergonomic improvement to me. I would like to avoid making a breaking change for the optional handler id, let me know your thoughts! I also made a change to remove some code reuse here: hgzimmerman#1
Avoid code reuse in agents
I still need to address the singleton id stuff, but I have merged your suggestions into this branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like 44aeb47 isn't quite right, can you fix?
Also, I think I have a good solution for HandlerId:
- Always insert into slab, whether Callback is
Some
orNone
- Change type of slab to accept
Option<Callback>
- Change HandlerId to (usize, bool)
- Add
is_respondable()
method toHandlerId
Not sure if this is completely done, but I'm sure it gets us closer to the implementation we want. Let me know if there is anything else that needs changing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add specific warning message if Agent tries to send message to handler with no callback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! There isn't a breaking change anymore, right?
Yes, I no longer think that this breaks anything. |
* Add Dispatchers, which act like bridges, but don't require a callback to create; updated router example * cargo fmt * improve comment * Another approach * add newtype around dispatcher bridges * added debug impl, run cargo fmt * fix example * make button on routing example start on loading variant * revert singleton_id changes * actually revert singleton_id changes * slabs own option<callback> * cargo fmt * remove dead lines * address bad doc comment * fix router example * fix handler id initialization in local agent * add appropriate error message when id is not associated with callback * remove misleading comment * use a type alias to the shared output slab
Addresses #307
Dispatchers are similar to bridges, but they don't require a callback to instantiate.
Dispatchers solve the problem of having to create
NoOp
messages that handle responses fromAgents
for components that do not care about them. This is a relatively common occurrence, and this change provides a significant ergonomic improvement over handling theseNoOp
cases.Dispatchers, when created, will not hook into the typical Component <-> Agent lifecycle. This is because they do not have
HandlerId
s. Soconnected
anddisconnected
will not be called whenAgent::dispatcher()
is called. You can send messages through them, which still reach thehandle
method on the Agent.Because of the lack of
HandlerId
s in dispatchers, a breaking change was required forAgent::handle
which now takes anOption<HandlerId>
instead of just aHandlerId
.Because it would be pointless to have dispatchers to
Job
andPrivate
discoverers, its usage is constrained to justContext
andPublic
discoverers.