so actually, is https://github.com/ztellman/aleph the most prominent cross-node communication library built on top core.async? or does it have a very different use case designation?

@matan not sure what you mean by built on top core.async, Aleph doesn't use core.async at all, it's based on its own async abstractions (deferreds and streams defined in Manifold library)

mmm thanks for the correction @gsnewmark

does the status clause down at http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html really represent current status, or is it more of a blog post frozen in time?

easing in into core.async, may I ask what does parking a thread, in simple terms, actually mean? http://clojure.github.io/core.async/#clojure.core.async/go

I've not found Java documentation very straightforward about "thread parking", whereas I gather (?!) this is the crux of why go blocks are favorable to simple blocking code. So I guess this is key to understand.

java thread parking is something entirely different

go blocks exist to avoid java thread parking more or less

what go blocks actually park is not something with a well defined name

logical thread is sometimes what it is referred to as

concretely, below the hood, the go macro turns clojure code in to a state machine, and parking means suspending execution of that state machine until some operation on a channel causes it to continue

so when you "park" a go block, the state machine is handed to the channel you are waiting for the operation(put or take) on as a callback, and once someone else does the reciprocal action on the same channel, the callback is scheduled to execute on a threadpool thread

@hiredman thanks so much, now I understand why 'parking' is quoted in the docs https://clojuredocs.org/clojure.core.async/go 😂

so parking is entirely "logical" as it is merely something in a state machine, which go blocks build from the code they wrap. I guess no I'm getting the hang of it.

under the hood, is there a single thread driving the state machine of all go blocks "active" in a given program?

there's a thread pool and go blocks are multiplexed onto the pool

@ghadi thanks. reading the core.async source now

hmmmm still not sure why the doc mentions threads or what they mean there about 'parking' again > will block (if necessary) by 'parking' the calling thread rather than tying up an OS thread https://clojuredocs.org/clojure.core.async/go

:thinking_face:

as I said there isn't really a consistent name for thread of control that exists in a go block

that wording is using "thread" to refer to the thread of control in a go block, and OS thread to refer to java.lang.Thread which is these days synonymous with an operating system thread

I see, a bit misleading in the function's docstring as such, but I'm confident about it once again now.

@hiredman many thanks!