Does anyone have any favorite core.async helper libs? E.g., full.async?

if I have a simple go block like this: (go (while true (receive/receiver (<! receive-chan)))) does the thread pool operate in such a way that the function receive/receiver could simultaneously run on different threads with different items taken from receive-chan? Or, does this block create a single process or thread that will handle all items?

the go block effectively becomes a series of one shot callbacks demarcated by parking channel operations (<!, >!, alt!)

so you have a single logical thread of control (each callback is called once and only one running at a time), but each callback may run on a different thread when it runs

so you can think of that code as something like ((fn f [] (when true (on/next-message receive-chan (fn [msg] (receive/receiver msg) (f))))))

@hiredman ah ok. i'm watching my cores on my laptop as that go block runs, and surprised to see all 8 of them light up from a single simple go block... that must be the multiple threads from the pool in action? It made me worry that there is a possibility that an item could be processed sooner than its previous item on the same channel was processed if they were simultaneous, but sounds like that is impossible in this case.

or you are spinning up more go blocks than you think

doubt it. that go block is top-level in the source file.

you likely re-evaled the source file creating a new go block

ah. now that it is indeed possible.

good catch.

never ever do side effects at the top level

hm, how to avoid that?

create a main function, have it start and kick anything off

if the go block was inside the main, re-running main would just be the same as a top-level go block, wouldn't it?

yes, but re-evaling the file doesn't re-run main

and I guess a scoped go block would stick around even after its surrounding scope goes away?

https://github.com/hiredman/clojure-site/blob/df56aef005d5d867213a51c2d3bbec5a86b0acad/content/guides/running_a_clojure_program.adoc

ajs: it depends

but it very easily can be the case

because go blocks turn in to call backs on channels, their lifetime is tied to the lifetime of the channels

so, i restarted the repl entirely. the code was only evaluated once. all 8 cores still light up from that go block. interesting. now stuff is streaming very quickly from a socket and dumping onto the socket, so perhaps the pool is getting quite a workout. though it would seem to me that a single physical thread to process the channel would seem more efficient than switching between threads, but perhaps not

opinions are split on it, but I highly recommend using something like component to manage runtime state in your program

i will need to read up on component and look at some tutorials. certainly heard of it but never used it