Fork me on GitHub
#core-async
<
2019-05-28
>
gordon05:05:13

yeah that's a good point, the order isn't defined with a/merge, so it wouldn't be strictly ordered by arrival time if you e.g. waited a few seconds to take from the merged channel of typical web service calls

👍 4
leontalbot13:05:16

Really interesting. In my case, as long as a have the fastest 4, I don’t care about the order within those 4.

leontalbot13:05:56

One thing I wonder is, if for some reason service is not available, how would you do a timeout to ensure this doesn’t block forever?

dpsutton13:05:53

merge takes channels so you could just add four (a/timeout your-preferred-delay) or if doing my original way make each request alt on the actual response or a timeout channel

🙌 4
leontalbot14:05:50

right, something like that:

(defn random-get [response-ch n]
    (a/go
      (let [wait (rand 4000)
            res (a/alt! (a/timeout wait) wait
                        (a/timeout 1000) :skipped)]
        (a/>! response-ch [n res]))))

(let [results-chan (a/chan 3 (take 4))]
  (a/go
    (dotimes [n 10]
      (random-get results-chan n)))
  (prn (repeatedly 4 #(a/<!! results-chan))))