Fork me on GitHub
#core-async
<
2016-12-16
>
nooga13:12:25

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?

donaldball13:12:18

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

nooga14:12:47

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

donaldball14:12:06

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

mccraigmccraig21:12:56

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

hiredman21:12:48

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

hiredman21:12:27

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

hiredman21:12:16

actually tons of other times as well

hiredman21:12:48

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

hiredman21:12:30

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

nooga22:12:38

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

nooga22:12:47

but this seems … delicate