This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-13
Channels
- # atlanta-clojurians (1)
- # beginners (148)
- # boot (13)
- # capetown (1)
- # cider (38)
- # cljs-dev (92)
- # clojure (61)
- # clojure-brasil (1)
- # clojure-dev (6)
- # clojure-italy (21)
- # clojure-losangeles (1)
- # clojure-nl (7)
- # clojure-norway (20)
- # clojure-spec (70)
- # clojure-uk (64)
- # clojurescript (69)
- # core-async (11)
- # cursive (6)
- # data-science (2)
- # datomic (50)
- # docker (2)
- # duct (12)
- # figwheel (1)
- # fulcro (81)
- # graphql (19)
- # jobs (3)
- # jobs-discuss (44)
- # keechma (1)
- # leiningen (1)
- # mount (2)
- # off-topic (10)
- # onyx (19)
- # parinfer (3)
- # portkey (6)
- # re-frame (4)
- # reagent (145)
- # reitit (1)
- # ring (1)
- # ring-swagger (2)
- # specter (1)
- # sql (4)
- # tools-deps (43)
- # unrepl (29)
- # vim (1)
What is the best way to deal with IO in a worker in an async manner? for example: I want a long running worker to poll sqs for messages(IO) and do a bunch of things with these messages. Should I then use a go block for all of it and make an additional thread (async/thread) for all IO?
definitely use thread for io, and read from the channel that thread returns
(if you need io inside a core.async context)
say 8 threads with a go block, we are “parked” on one thread trying to read from SQS say. so then the threads get released into the pool until we get the messages from sqs and everything resumes as normal. same thing with using a thread in a go block right? except instead we spawn an additional thread, but the go block is still parked on getting a results from the thread channel, so the result is the same, right?
ah wait i see, when we try to read from SQS in a go-block we aren’t releasing the other threads into the pool since its not an async take
thread returns a channel, parking on a channel doesn't block
right - if you read from sqs in the go block itself you do block