Open tomtzook opened 9 months ago
Same goes for default actions waiting really.
Could make a list of "requests" for running on a subsystem and when a subsystem is freed, alert that an action is ready to start.
It would also solve a potential problem of new action superseding the pending action. Though maybe we don't want to go into a queue methodology.
Allow also rejecting incoming actions instead of just pending them.
When a new action first encounters a preferred action, it discovers so in the conflicts check. It is then placed in the pending list, as seen in
SingleThreadedScheduler.start
andSingleThreadedScheduler.tryStartingAction
. However, for each subsequentScheduler.run
call until the preferred action stops, the pending action will do the same requirements check again and again. Time may be optimized into a push event instead of pulling on the requirements again and again.One possibility is to require the running action or the relevant requirement to hold a queue of waiting actions and inform them once the requirement was released.
The same is true for default actions, as
SingleThreaded.Scheduler.canStartDefaultAction
is checked way too much and it requires multiple loops.