-
Notifications
You must be signed in to change notification settings - Fork 574
Add actor concurrency model(similar to Elixir) #17214
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
base: compatible
Are you sure you want to change the base?
Conversation
892ba18
to
928e19f
Compare
!ci-build-me |
!ci-bypass-changelog |
NVM, somehow rerun CI fixed the issue. |
!ci-build-me |
!ci-build-me |
MNext state | ||
| RExit resp -> | ||
(* NOTE: for some reason OCaml can't infer this type here *) | ||
Ivar.fill response_ivar (Obj.magic resp) ; |
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.
Unfortunately OCaml can't infer the type here :(
!ci-build-me |
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.
Please add a doc-comment to each module defined in actor.ml
.
Please describe tests in terms of which workflow they simulate and how.
Added all descriptions in a interface file. |
!ci-build-me |
Next in train: #17224
NOTE: CI Nightly is passing in the last PR in this train: #17225
NOTE2: This indeed needs careful review, I've spotted several bugs already.
Purpose
This is Actor model, going to be used to refactor transition router. Well, not strictly because it also supports a server model where an actor could process requests and return responses.
Potential Improvements
For now we only have 3 inboxes for an Actor:
request
,control
anddata
, in that priority order.request
support handling dependently typed requests defined by GADTs.control
is just a normal queue that never drops any messages.data
is supposed to partially simulatestrict_pipe
's behavior.This model could be generalized to any number of channels. Utilizing Heterogeneous Lists. This could further be refactored using a heterogeneous priority queue so messages can have customized priority. But it seems for now we don't have a good use case of such actor.
Benefits
Hooking into an actor
If everything is modeled as actor, we could design a supervisor system by hooking into Actor implementation, and then we can have a good flamegraph implementation knowing at which time, which actor is running.
Inspecting an actor
You could just look into the struct to inspect what messages in queue an actor has, and its state. Previously all such abstraction is inside lambda functions -- You just can't identify an lambda without some quirks I guess.
Mitigate concurrency issues
The very reason I'm trying to introduce this is
Transition_router
has some nasty synchronization bugs, I haven't been able to figure out the fix even knowing the issue. One of the blockers is that there's virtually no good way to debugAsync
code due to everything being lambda, and abusingdon't_wait_for
made the code worse.