Clojurians Log v2
Clojure programming
Channels
Apps
core-async 2026-02-11
dpsutton 2026-02-11T15:38:37.297509Z
We have a PR up with the following at work:
(a/go
(let [result (a/<! finished-chan)]
(try
(ThreadContext/putAll mdc-ctx)
(log-info (assoc info :async-status (name result)))
(finally
(ThreadContext/removeAll (keys mdc-ctx))))))))ThreadContext is (org.apache.logging.log4j ThreadContext). This feels strange to me. Doing thread local work from a go block feels fundamentally wrong. But is it possible with such a small lexical scope there’s no cooperative scheduling and this will necessarily run from a single thread and then pop the context?
I’m not actually sure if the go macro machine can make the whole go block interruptible at any point or if it’s more cooperative at alts! and such where it parks itself.
Alex Miller (Clojure team) 2026-02-11T15:52:17.222999Z
the go block only parks on channel operations
👍 1
Alex Miller (Clojure team) 2026-02-11T15:52:38.162419Z
so this should be fine
dpsutton 2026-02-11T15:53:11.763599Z
Ok. It set off a spidey sense but I'm glad to hear it's fine
Alex Miller (Clojure team) 2026-02-11T15:54:41.578629Z
the go machine CAN make it interruptible at any point, but it does not currently, and I can't foresee that changing :)
it's the sort of qualified 'fine' when you rely on impl details
can't this be a take! callback and thus run unshredded?
dpsutton 2026-02-11T16:04:33.953189Z
it probably can. I just didn’t know if it was worth raising an issue about in the PR. Also i love the “shredded” terminology
dpsutton 2026-02-11T16:06:23.773489Z
and it does invite people to add more channel ops in the go block in future at which point the thread mechanism will be wrong. So probably good to not even leave the invitation
yes. not likely to break because of core.async, but because of your own dang self
dpsutton 2026-02-11T16:07:45.438909Z
thank yall for your thoughts