I think i managed to make a clean version of throttle-chan that doesn't need more than one go-loop and doesn't use atoms

(defn- throttle-chan [in-chan out-chan valve-chan]
  (async/go-loop [allowance 0]
    (if (< 0 allowance)
      (do (async/>! out-chan (async/<! in-chan))
        (recur (reduce (fn [val f] (f val)) allowance (take-while (complement nil?) (repeatedly (fn [] (async/poll! valve-chan)))))))
      (let [f (async/<! valve-chan)]
        (recur (reduce (fn [val f] (f val)) (f allowance) (take-while (complement nil?) (repeatedly (fn [] (async/poll! valve-chan))))))))))

@bcbradley Doesn't this have the issue of out-chan potentially blocking valve-chan?

Even in-chan can block valve-chan in this version AFAICT

You need to include all your takes and puts in an alt! or alts! (or perhaps you can even work something out with poll!) to prevent that

@dergutemoritz i've thought about it for a while and came to the conclusion that because you must "hold" the value you get from the in-chan before sending it off to the out-chan

and because during that "hold" you could potentially receive a value from valve-chan unless you block it,

and because that value could assign 0 to allowance

it isn't logically self-consistent

what would you do with the value you held if you are told from the change in allowance that you aren't allowed to push it to the out-chan?

do you put it back on the in-chan?

thats potentially a way to go, but it mixes up the order of stuff

basically, if you want to preserve the order, and you don't want to allow the valve chan to invalidate the thing you "hold"

then you have to block the valve chan while you hold it

thats the only way

if there were a way to forcibly push something backwards into a channel, it might be possible to rewind without reordering

OK if that's fine then I'm sure your function can be simplified 🙂

i mean if you've got some insight i don't please share it

i never imagined throttling would be such a deep rabbit hole

Well yeah, if an allowance change comes in while you wait for out-chan to become available but you've already taken a value from in-chan, the semantics are a bit hazy indeed 🙂

Not sure if blocking in this case is ideal either, though

i'm considering not blocking but not preserving order either

i don't know how i feel about that

i don't feel like a throttle should be mucking with the order

What order exactly would be mucked with, though?

You would check the allowance after taking but before waiting for the put

right

and if the allowance became zero while you were taking

then you'd put it back on the in-chan

ready to take again later

If an allowance change comes in then, you would potentially put something at a point in time where the already taken value would not be allowed anymore but you would still put it into out-chan before any next value that comes through in-chan

Oh I thought you threw away values which were taken while allowance is 0

the allowance is basically how many values you will allow to go from in-chan to out-chan

So you don't want to lose values, yeah?

right no loss

IC

the valve-chan is a way of modifying the allowance

the issue is that someone could set the allowance to zero through the valve-chan, and expect it to freeze the flow of stuff from in-chan to out-chan

however, actually implementing a perfect freeze is hard

if you are in a state where you already took from in-chan and are ready to put to out-chan, thats where the rabbit hole starts

after working with different solutions for a couple days I finally came to the conclusion that the issue is my assumptions

i assumed that the valve-chan, in-chan, and out-chan shouldn't block eachother

or atleast shouldn't have to

i think i was wrong to make that assumption

it seems making that assumption isn't logically consistent with the semantics of a throttle

a throttle doesn't know anything about data being "half" commuted

Yeah makes sense

These things can be really tricky, indeed

well atleast i'm happy with my current solution

one go-loop, no atoms, pretty simple

it also doesn't spin

that the big thing i was trying to avoid

BTW, both your and mine don't currently properly handle closing of any of the channels involved

In fact, my version is a bit different: it will also allow changing the allowance when it's > 0 while nothing is coming in through in-chan