Cycle priority flag on timers

Open
  • Is something wrong?
#351 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
cpp, python
Domain
stream-processing

Research direction

Start by tracing csp.timers, csp.sample, csp.feedback, and the TimerHeap mentioned in the issue. Review how duplicate timestamps are ordered, then determine how FIRST, LAST, and FINAL priority should interact with feedbacks. Done means timer priority is controllable and the stated feedback semantics are enforced.

Written by the indexing model from the issue text.

Description

type: enhancement

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 )

Dominant language
Python
Stars
450
Forks
91
Avg merge
18h 8m
Merged PRs (30d)
3

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Point72/csp

All issues in Point72/csp

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.