Fork me on GitHub

In JVM core.async, can I assume that each chan when created/opened is a dedicated process/thread that doesn't change, and the process is never the main thread?


channels are not tied to threads at all


think of them like java.util.concurrent Queues


@ghadi for example, this from the Brave True book: "Everything within the go expression—called a go block—runs concurrently on a separate thread."


yup, you asked about channels, not go blocks 😃


go blocks run on "threads" with air-quotes


there is a pool of threads, and go blocks run in the thread pool until they cannot anymore, then another go block takes its place


they're green threads


True, so my question is whether the taking of items off a chan in a go block will process the items sequentially all in the same thread/process, or if items could be processed on different processes


In cljs it's the same idea, but using the event dispatch loop instead of a pool


yeah, if you are descheduled between items (let's say pulling an item blocks for a bit) you might get the next item from a different physical thread


but you really shouldn't be caring about the physical threads, except to understand the machinery


What is the typical idiom for using go blocks to deliberately put things onto different threads vs manually spawning futures, which I normally do.

Alex Miller (Clojure team)19:03:27

channels are for enduring relationships so if the “threaded” work is going to stick around and communicate more than once, then consider a go block

Alex Miller (Clojure team)19:03:37

otherwise future probably makes more sense


With futures, I'd have to be careful how many I spawn, right?

Alex Miller (Clojure team)19:03:53

maybe. other equally important questions are how often you spawn and how long your tasks take to complete

Alex Miller (Clojure team)19:03:59

and whether they may block

Alex Miller (Clojure team)19:03:28

go blocks should never block on io


So, simultaneous futures in operation have a hard limit since each is a physical thread,right?

Alex Miller (Clojure team)19:03:01

yes, but if you are finishing work fast enough, you will only use a small number


Is there a way to know what that limit is?

Alex Miller (Clojure team)19:03:54

it again depends on lots of factors, like how much heap you have


and there are sort of levels of limits, if you have 4 cores, at most you will only be executing 4 things at once, even though your os will time slice threads across those 4 cores