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 and SingleThreadedScheduler.tryStartingAction. However, for each subsequent Scheduler.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.
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.startandSingleThreadedScheduler.tryStartingAction. However, for each subsequentScheduler.runcall 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.canStartDefaultActionis checked way too much and it requires multiple loops.