New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Iterant[Task].intervalAtFixedRate #516

Closed
alexandru opened this Issue Jan 12, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@alexandru
Member

alexandru commented Jan 12, 2018

For Observable we have:

No 1 — Observable.intervalWithFixedDelay — generates ticks with a fixed delay between them, such that when you have something like this ...

Observable.intervalWithFixedDelay(5.seconds).mapTask { _ =>
  Task.eval(println("tick")).delayExecution(3.seconds)
}

This logic will print "tick" every 8 seconds, because the source gets back-pressured and the delay is fixed.

No 2 — Observable.intervalAtFixedRate — generates ticks at a fixed rate, like the above but substracts the time it took for the consumer to consume the tasks, trying to keep the spacing between the starts fixed:

Observable.intervalAtFixedRate(5.seconds).mapTask { _ =>
  Task.eval(println("tick")).delayExecution(3.seconds)
}

This piece of logic will print "tick" every 5 seconds, because the 3 seconds it takes for those tasks to execute is taken into account and subtracted from the 5 seconds period.

Your Task, Should You Choose to Accept It

We already have Iterant.intervalWithFixedDelay implementated.

We need intervalAtFixedRate with the same contract as for Observable.

Lets note the duration of the downstream tasks (the rest task at each step) with taskDuration.
The contract is:

  1. if taskDuration <= period then the delay is period - taskDuration
  2. if taskDuration > period then the delay is zero
  3. obviously two tasks cannot run in parallel, so the actual tick can take longer than the specified period, but that's fine, it's the same contract as on Observable

You can also checkout IntervalFixedRateObservable for inspiration.

Other Considerations

The implementation is specialized for Task because with Task we can express .delayExecution without any ExecutionContext or Scheduler needed in scope.

This is OK for now, subject to change in the future.

Good luck 😀

@alexandru alexandru added this to the 3.0.0 milestone Jan 12, 2018

@oleg-py

This comment has been minimized.

Collaborator

oleg-py commented Jan 12, 2018

I would like to take a shot on this :)

@alexandru

This comment has been minimized.

Member

alexandru commented Jan 12, 2018

@oleg-py go for it 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment