You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, even if running in coroutines and using channels to distribute the workload, the entire application is (essentially) single-threaded, as we only start one coroutine per task (listener, pub/sub, etc.)
We should explore the possibility of running the workers concurrently - however, this opens up the possibility of race conditions for events which, even if arriving in order from SQS, may become out-of-order (and cause unwanted issues, with transitions being deemed invalid, incorrectly).
It is non-obvious how to "single-thread" per FSM, while keeping independent event stream running concurrently.
The text was updated successfully, but these errors were encountered:
Currently, even if running in coroutines and using channels to distribute the workload, the entire application is (essentially) single-threaded, as we only start one coroutine per task (listener, pub/sub, etc.)
We should explore the possibility of running the workers concurrently - however, this opens up the possibility of race conditions for events which, even if arriving in order from SQS, may become out-of-order (and cause unwanted issues, with transitions being deemed invalid, incorrectly).
It is non-obvious how to "single-thread" per FSM, while keeping independent event stream running concurrently.
The text was updated successfully, but these errors were encountered: