Point72
Cycle priority flag on timers
Right now, due to how CSP manages duplicate timestamp cycles, all csp.timers that are scheduled will always execute in the first cycle of the given timestamp ( even if there are more data points scheduled for the same timestamp ) This can cause issues if for example you want to csp.sample with a csp.timer. In many ( perhaps most ) cases you would want to sample the last point of the timestamp rather than the first, but there is no way to control this at the moment.
The other thing we can do if we controlled priority is to allow a "last cycle" timer. This would include managing feedbacks that are introduced mid-cycle, which would then potentially allow us to implement the ever elusive "csp.reroll" ( picture ts[list] -> csp.unroll -> process individual ticks -> csp.reroll back into the original list )
Thinking out loud, we can potentially have 3 priority modes for csp.timers / alarms:
- Priority.FIRST - with first cycle for the timestamp
- Priority.LAST - with last timestamp of the cycle ( will execute after everything scheduled up to this point, but not things scheduled after )
- Priority.FINAL? ( not stuck on this name ) - ultimate last cycle of the given timestamp
LAST can be fed into csp.feedback, FINAL should raise if its wired into a feedback since that would break its semantics.
Implementation wise, we would have to introduce a priority to timestamps in the TimerHeap ( can probably embed it in the timestamp going into the existing ordered map )
