This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-31
Channels
- # admin-announcements (1)
- # beginners (16)
- # boot (25)
- # braid-chat (7)
- # cider (4)
- # cljsfiddle (6)
- # cljsrn (1)
- # clojure (256)
- # clojure-austin (4)
- # clojure-ireland (1)
- # clojure-poland (15)
- # clojure-russia (80)
- # clojure-uk (2)
- # clojurescript (30)
- # core-async (14)
- # core-typed (3)
- # cursive (35)
- # datomic (1)
- # editors (28)
- # hoplon (32)
- # immutant (1)
- # jobs (8)
- # jobs-discuss (1)
- # juxt (6)
- # leiningen (8)
- # liberator (7)
- # off-topic (16)
- # om (69)
- # onyx (38)
- # re-frame (10)
- # spacemacs (1)
- # untangled (117)
My impression is that the go-loop in the background will take values as they are added to the channel and the map function will fill the channel as space becomes available
Okay cool thanks! I also discovered that adding to a channel with map results in lazy list and won't put the results in a channel so you have to force it with a doall/doseq/dorun
Hi all, I’m trying to figure out if we’re affected by ASYNC-138. So am I right that any go-block internal reference to objects defined outside the go-block is a potential source of mem-leaks?
values closed over by go-blocks will not be GC'ed until the go block itself gets GC'ed, and if the go-block is for example, a go-loop that recurs infinitely, then those objects will never be freed.
I think it's good advice to do as little as possible actually inside the syntactic go block anyways
primarily coordinating with channel ops and calling (ideally) pure functions that transform data