This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-19
Channels
- # announcements (9)
- # babashka (5)
- # babashka-sci-dev (23)
- # beginners (160)
- # calva (78)
- # cider (23)
- # clj-commons (2)
- # clj-kondo (5)
- # cljdoc (19)
- # cljs-dev (8)
- # clojure (54)
- # clojure-australia (1)
- # clojure-czech (2)
- # clojure-dev (17)
- # clojure-europe (8)
- # clojure-italy (8)
- # clojure-nl (2)
- # clojure-sg (3)
- # clojure-uk (4)
- # clojurescript (70)
- # community-development (8)
- # core-async (8)
- # cursive (7)
- # datahike (12)
- # datalog (22)
- # datomic (20)
- # events (1)
- # fulcro (43)
- # graalvm (92)
- # gratitude (5)
- # holy-lambda (77)
- # honeysql (1)
- # jobs (1)
- # lsp (111)
- # membrane (70)
- # nextjournal (13)
- # off-topic (73)
- # pathom (1)
- # polylith (8)
- # portal (32)
- # re-frame (3)
- # reagent (4)
- # reitit (5)
- # releases (2)
- # reveal (4)
- # xtdb (22)
I am trying to understand how core.async parking works.
In the documentation of go
, I see:
any visible calls to <!, >! and alt!/alts!channel operations within the body will block (if necessary) by'parking' the calling thread
I'd like to understand if the parking happens before or after the arguments are evaluated.
For instance, in a piece of code like this:
(go (>! c (do-some-heavy-computation)))
Could the parking occur before (do-some-heavy-computation)
is evaluated?no, I don't think so
Cool. For my use case, this is what I was expecting. Is it an implementation detail or is it by definition? In other words, could it change in a future version of core.async?
if you're worried about it, eval in a let prior
But then it might behave a bit differently. This is exactly what I'm trying to figure out: does "eval in a let prior" woks the same or not?
I do not think this is explicitly specified in core.async anywhere what the evaluation semantics of a parking op is wrt evaluating args, so I'd say it is subject to change (not that there are any plans to change it). for example, if the impl was swapped with new Project Loom constructs, would it be identical? I don't know.
I would expect a value that is computed prior to the call to be computed prior to the parking regardless though
Thanks for the clarification