I’m trying to make a “http client worker” that recieves requests via chan, and once it has the response, it sends it back to the requester via another chan. Requests contains the chan that the worker should respond on. Is it a good practice? Sending channels on channels?

I’ve done something similar before, but I think I wound up sending promises instead

something like (defn client-req [client params] (let [p (promise)] (>!! (:chan client) {:req params :promise p}) p))

?

Basically. The semantics of promise better fit my use case.

why dyu want to do that @nooga ? are you wanting to control the # of concurrent requests with a buffered channel or something ?

I've done things like that for sort of async REST requests

you make a rest call somewhere, and it is going to call you back with the answer later

actually tons of other times as well

any time I want to get io off of go blocks, usually I have some thread pool where the io is done

so for go blocks to do io they submit tasks to the threadpool and those tasks write their results to a channel when the io is done

@mccraigmccraig yeah

i thought about decoupling it completely and somehow keeping registry of which response is for which request

but this seems … delicate