This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-03
Channels
- # beginners (167)
- # boot (22)
- # chestnut (3)
- # cider (9)
- # clojure (107)
- # clojure-berlin (1)
- # clojure-greece (3)
- # clojure-italy (6)
- # clojure-losangeles (6)
- # clojure-russia (8)
- # clojure-spec (71)
- # clojure-uk (42)
- # clojurescript (186)
- # community-development (1)
- # core-async (12)
- # core-typed (1)
- # css (15)
- # cursive (29)
- # data-science (11)
- # datomic (8)
- # defnpodcast (28)
- # duct (2)
- # fulcro (169)
- # graphql (6)
- # hoplon (3)
- # jobs-discuss (1)
- # kekkonen (5)
- # leiningen (11)
- # lumo (7)
- # off-topic (14)
- # om (1)
- # other-languages (14)
- # portkey (7)
- # re-frame (27)
- # reagent (14)
- # remote-jobs (1)
- # ring-swagger (5)
- # rum (15)
- # shadow-cljs (52)
- # spacemacs (59)
- # specter (78)
- # test-check (3)
- # vim (9)
- # yada (23)
what does it mean if (take! c f) calls f as expected if I haven’t started my app, but if I have started my app it only calls f if c already has data queued
does this mean that something is starving the put queue or the go threadpool?
(it’s likely there’s something bad going on in core.async world after a radical change to a lib, but I’m wondering how to look at and identify the specific problem, beyond looking very hard at the code until I see what is wrong)
is there a good approach beyond guessing and reading jstack output?
considering that everything is owned by the core.async threads so it can be hard to see where things are happening
yup, that must be it, it failed to print
so somebody is blocking all the go blocks, good to know
the core.async threads will be tagged with "async-dispatch-" when you look through jstack
OK - yeah, I found them, all blocking on the same code, thanks for the suggestions