This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-03
Channels
- # adventofcode (151)
- # asami (34)
- # babashka (43)
- # beginners (111)
- # cider (2)
- # clj-kondo (6)
- # cljdoc (12)
- # clojure (140)
- # clojure-australia (10)
- # clojure-europe (14)
- # clojure-france (5)
- # clojure-gamedev (5)
- # clojure-nl (4)
- # clojure-uk (10)
- # clojurescript (20)
- # community-development (9)
- # conjure (1)
- # core-async (4)
- # cryogen (3)
- # cursive (2)
- # datomic (17)
- # emacs (9)
- # events (1)
- # fulcro (27)
- # juxt (8)
- # kaocha (2)
- # lambdaisland (14)
- # off-topic (23)
- # pathom (37)
- # pedestal (2)
- # re-frame (8)
- # reagent (8)
- # reclojure (9)
- # reitit (5)
- # reveal (34)
- # shadow-cljs (27)
- # spacemacs (10)
- # tools-deps (123)
- # vim (28)
- # xtdb (17)
@alexmiller based on a discussion in #clojure I took another look at https://clojure.atlassian.net/browse/ASYNC-225 and decided their root cause analysis didn't go far enough, so their conclusion (they need a new feature, non-shared timeouts) was faulty. I dropped a patch on the ticket that I think solves their real issue (the non-selected channel operations in an alt retain a reference to closed over data potentially indefinitely), without adding a new feature. The ticket however is still tagged as a 'new feature' and 'minor', so I wanted to ping you because I think my patch solves their root issue, doesn't add a new feature, and has a large potential impact on memory usage in core-async heavy programs.
https://clojure.atlassian.net/browse/ASYNC-234 is the new ticket, I'll move the patch over, and see if I can get some graphs of differences in memory use pre/post patch
thanks, that is a good writeup