jkk
Modify rate-gate to use future instead of a separate thread
This has the following benefits:
Does not require separate Thread creation per function rate-gated, which can be an issue if you wish to rate-gate lots of functions independently of one another. Instead, we utilize the thread pool that futures execute on.
Simplifies RateGate object by eliminating list of exit times and thread object. Reduces usage of Java objects, preferring Clojure-isms instead. Removes unnecessary extra logic associated as well.
Yes, your argument does make sense. I was trying to figure out a way to wrap a large number of functions without requiring a thread per rate-gate, and I was under the impression that futures utilized a fixed sized thread-pool (which it does not). Although now I believe/realize having a shared monitoring thread does have it's own set of complications that breaks the desired semantics. Thanks, back to the drawing board.
I have tried again, this time using core.async. Of course, it may not make sense to pull in for now since core.async is still only a SNAPSHOT release, but I believe it accomplishes what I was originally hoping to do. It does not require an explicit management thread per function rate-gated, nor does it create a thread per function call, and includes tests to attempt to verify that this is true.
Hi @osbert - thanks for sending an update. Would you like commit access to this repo? I honestly haven't looked at this lib in a long time and won't be able to review or provide much help.
