Fork me on GitHub

so actually, is 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 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?


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 😂


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




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.