Fork me on GitHub
Yehonathan Sharvit13:10:30

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?

Yehonathan Sharvit13:10:41

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?

Alex Miller (Clojure team)13:10:01

if you're worried about it, eval in a let prior

Yehonathan Sharvit13:10:31

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?

Alex Miller (Clojure team)13:10:51

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.

Alex Miller (Clojure team)13:10:44

I would expect a value that is computed prior to the call to be computed prior to the parking regardless though

Yehonathan Sharvit13:10:49

Thanks for the clarification