This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-19
Channels
- # bangalore-clj (2)
- # beginners (217)
- # boot (3)
- # cider (130)
- # cljs-dev (117)
- # cljsrn (11)
- # clojure (99)
- # clojure-china (1)
- # clojure-denver (1)
- # clojure-dev (22)
- # clojure-italy (30)
- # clojure-norway (5)
- # clojure-russia (13)
- # clojure-sanfrancisco (3)
- # clojure-spec (74)
- # clojure-uk (107)
- # clojurescript (40)
- # clr (6)
- # core-async (25)
- # core-logic (4)
- # cursive (1)
- # data-science (1)
- # datomic (62)
- # duct (11)
- # editors (14)
- # figwheel (3)
- # fulcro (12)
- # funcool (1)
- # garden (12)
- # graphql (19)
- # jobs (4)
- # jobs-rus (1)
- # lein-figwheel (1)
- # leiningen (12)
- # luminus (5)
- # off-topic (45)
- # onyx (12)
- # other-languages (1)
- # parinfer (5)
- # programming-beginners (3)
- # re-frame (113)
- # reagent (63)
- # remote-jobs (10)
- # ring-swagger (1)
- # shadow-cljs (31)
- # slack-help (3)
- # spacemacs (27)
- # specter (1)
- # unrepl (44)
- # yada (16)
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?
@ghadi for example, this from the Brave True book: "Everything within the go expression—called a go block—runs concurrently on a separate thread."
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
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
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.
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
otherwise future probably makes more sense
maybe. other equally important questions are how often you spawn and how long your tasks take to complete
and whether they may block
go blocks should never block on io
non-channel io thati s
So, simultaneous futures in operation have a hard limit since each is a physical thread,right?
yes, but if you are finishing work fast enough, you will only use a small number
it again depends on lots of factors, like how much heap you have