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
I want to be explicit about how dispatched signals are scheduled for processing. This is particularly important in the context of cascading signals, where a secondary signal is generated from within an action (triggered by a prior signal).
In the case of secondary signals, processing should be queued for after completion of the current and any pending signals.
In the case of primary signals (triggered by user action), I'm less certain but inclined to give the same treatment.
This should (a) allow easier reasoning about the timing of actions and (b) improve performance by breaking up otherwise long running processes.
The text was updated successfully, but these errors were encountered:
I want to be explicit about how dispatched signals are scheduled for processing. This is particularly important in the context of cascading signals, where a secondary signal is generated from within an action (triggered by a prior signal).
In the case of secondary signals, processing should be queued for after completion of the current and any pending signals.
In the case of primary signals (triggered by user action), I'm less certain but inclined to give the same treatment.
This should (a) allow easier reasoning about the timing of actions and (b) improve performance by breaking up otherwise long running processes.
The text was updated successfully, but these errors were encountered: