[Feature Request] Add atomic `.dec()` to complement `.inc()` apis

[johnpyp]

One api I feel is missing from the current surface is an atomic .dec() on both the current size but also the length of the progress bar. In a similar vein, a .inc() api which doesn't impact rate calculations, somehow, could be useful.

Here's the usecase I found myself building recently that seemed like it needed it:

An rsync-like utility which synchronizes files, but only does meaningful work on files which haven't changed. The progress bar length may reflect the sum total of files from source which could be synchronized, but over time the tool makes cheap requests that invalidates most of those files due to being transferred previously already. In this case, I'd like the progress bar to only reflect files which have actually been "transferred".

However, I can't do an atomic dec on the length (and not .inc() the size at the same time) to indicate "skipping" an element, where the stats of the progress bar would still be coherent. Currently, just using .inc() on the size, would end up filling up the progress bar only partially.

If I go the other route, and always .inc() every file even if it was just a cheap check, the rate calculations of the progress bar get artificially inflated - e.g it'll say I'm transferring 100 Tbps if I'm measuring bytes.

In this case, having a .dec() would allow the progress bar to stay coherent, and the rates to make sense because I'm not over-incrementing.

To address the obvious current way to sort-of do this, just setting the length or size isn't thread safe and in parallel programs would be very likely to add some accuracy problems.

---

My second proposal is the .inc() which doesn't impact rate calculations. The idea here is, given a scenario like above, you may want a progress bar which stays at a constant length but still has coherent "transfers per second" or "bytes per second" values, while still ticking up the progress bar.

---

Let me know if the motivation for these features makes sense, and I can further elaborate and potentially implement a poc / PR for them.

[djc]

I sort of understand the motivation, but I'm skeptical that it will fit well within indicatif's design. However, open to reviewing a PR that adds surface-level API with hopefully minimal internal changes.

[jaheba]

I see the point of adding .dec() analogous to .inc(), since .set_position() is not atomic.

The same could be said for .set_length(): There is .inc_length() which locks the state, but there is no dec_length().

My second proposal is the .inc() which doesn't impact rate calculations. The idea here is, given a scenario like above, you may want a progress bar which stays at a constant length but still has coherent "transfers per second" or "bytes per second" values, while still ticking up the progress bar.

I think that would not be possible with the current design of the estimator. It updates in time intervals, not steps. It looks at the delta between t and t-1 to update its estimate. Your proposal would mean that there are two pos (and possible length) values, one for the progress bar and one for the time/throughput estimate.

[johnpyp]

Yeah that makes sense, the latter I wasn't sure was possible anyways.

Thanks both, I'll open a PR for .dec()

[djc]

(@jaheba already opened #690.)