Add debounce operator for observable #1978
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1978 +/- ##
==========================================
+ Coverage 71.63% 71.71% +0.07%
==========================================
Files 658 659 +1
Lines 29118 29198 +80
Branches 3171 3182 +11
==========================================
+ Hits 20859 20939 +80
- Misses 6448 6450 +2
+ Partials 1811 1809 -2 ☔ View full report in Codecov by Sentry. |
53832f7 to
aa32979
Compare
|
I thought about this implementation for a bit now. Just commenting my thoughts about it at the moment, so please make no changes yet. The time management seems correct, but it'll request a timeout on each item. This means if the input sequence has a burst of items, we'll trigger a burst of new timeout requests and cancellations. Maybe we can re-organize that to not cancel an already pending timeout and only after it fires do we look if we need to sleep for some extra time (new items arrived since then). Timeouts are handled by the central clock, so having a burst of timeout requests and cancellations will stress the clock potentially a lot - locking a mutex each time. The way we currently handle demand does not seem correct to me. This implementation gives the input source infinite credit and then silently drops items if the observer didn't signal demand in time. We should signal no demand upstream until the observer requested at least one item. However, it's not that simple actually, because we will use up the credit only after a timeout trigger. The source will still have demand at that point, so there's an edge case where we use up our last demand and then get a new item. We could just store that without firing up a timeout, basically delay normal operation until we get new demand again. It's not going to be simple either way. |
Relates #1389