visig9/slottle

A rust throttle pool library designed for thread-based concurrency.

slottle's Issues

Proposal: Change retry related API

Problems

Consider:

1. Anything that need to be throttled by access speed are potential may failed (or else we don't need to throttle them, just let it blocking). Retrying interface should be the primary interface. Not an add-on.

   • [Added 2020-12-05]: An exception need to considering: local resources usage, e.g., CPU or threads or harddisk IO. If we don't control (throttle) them usage then it will failure like any other remote resources. But before program get the error message the host computer will crash or become very lagging first.
     • So, in this case, program will not receive any error before system crash. That mean: non-failable throttling still has it use case.

2. Logically, interval can be treat as the "first element" of rseq. But ours API not reflect that truth.

Want can we do

• Remove retrying feature and let related facility built-in.
  • Rename .run_retry() to .retry(...) for simplify.
• Keep original .run(...) API as escape hatch
  • Rename it to .once(...) for cleaning.
  • (really needed to keep this one, or just delete it?)
• Offer a new builder API: fn intervals<T: IntoIterator<Item = Duration>>(rseq: I). Use case:
  • Fixed delay 5 time: builder.intervals(vec![Duration::from_millis(10); 5]
  • Random delay 3 time: builder.intervals([Duration::from_millis(10)].iter().chain().cloned().map(uniform).take(3))
  • Infinite retrying: builder.intervals([Duration::from_millis(10)].iter().chain().cloned())
  • (consider name it as retry_intervals() due to this sequence is related to retrying sequence, not related to job sequence?)
• Keep .interval(...) the same. but let it alias to builder.intervals([Duration::from_milis(10)].iter().cycle().cloned())
  • (re-thinking: infinite retrying may danger, this API may too easy to trigger)
• Remove builder's fuzzy_fn API.
  • Due to partial overlay with intervals(...). Too easy to confuse user.

More potential retry API Change

• Give an option to let retry sequence "interruptable" -- release concurrent quota every time before a chance to retry. (so concurrent quota can be take by other jobs)
• More powerful interval control: add a new builder function may look like: (API should be thinking carefully)
  • fn intervals_fn(fn(retry_count: u64, last_retrying_delay: Duration, my_retrying_total_delay: Duration, pervious_interval: Duration) -> Duration)
  • This may be can allow user to write some dynamic throttling logic (automatic speed adapting)