This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-18
Channels
- # alda (6)
- # architecture (1)
- # bangalore-clj (3)
- # beginners (39)
- # boot (292)
- # braveandtrue (1)
- # cider (7)
- # clara (2)
- # cljs-dev (20)
- # cljsjs (9)
- # cljsrn (42)
- # clojure (127)
- # clojure-chennai (1)
- # clojure-dev (96)
- # clojure-india (1)
- # clojure-russia (175)
- # clojure-spec (56)
- # clojure-uk (11)
- # clojureindia (1)
- # clojurescript (82)
- # core-async (7)
- # cursive (21)
- # data-science (1)
- # datomic (173)
- # funcool (4)
- # hoplon (8)
- # instaparse (1)
- # jobs (7)
- # jobs-discuss (1)
- # jobs-rus (30)
- # lambdaisland (1)
- # lein-figwheel (8)
- # off-topic (5)
- # om (51)
- # onyx (79)
- # other-languages (7)
- # planck (8)
- # re-frame (95)
- # reagent (6)
- # rum (8)
- # specter (4)
- # untangled (54)
- # yada (5)
It's recommended to avoid performing IO in go blocks. What about logging? Is logging IO ?
I think the question is, can it block arbitrarily long. Technically for logging, the answer is yes. Practically, the answer may be no.
Some people run logging through an agent so there’s a queue in the middle (but beware that agent queues are unbounded)
what happens if your logger can’t keep up?
just something to think about
@alexmiller: thanks, I'll check into my logger libs to find the answer. AFAICT the typical logging time is ~1ms
right, typical logging is unlikely to be an issue. the question is what happens in atypical cases (run out of disk space, rolling a log file, you get a burst of 1000 log messages at the same time, etc). how much you care about that stuff and how likely it is are specific to your app.