How do go blocks "unpark" themselves? IIUC , when they part they release the thread to work on another go block. What tells the thread that the first go block is ready to be worked on again?

@xiongtx go blocks don't park as much as they turn themselves into a callback (could be though of as a continuation). So when they "park" they simply attach a callback to something. Most of the time it's handed to a call ot (async/put! c v callback)

@tbaldridge Found this extremely helpful walkthrough of core.async/go: http://hueypetersen.com/posts/2013/08/02/the-state-machines-of-core-async/ IIUC the channel is responsible for restarting the state machine.

there’s an async-dispatch process that matches up channel reads and writes to resumption of pending reads and writes in eligible go blocks (expressed as callbacks)

the channel itself is a queue used by that disptach process as I understand it

(though now that I think of it more there must be a mechanism that marks the channel for potentially activating go blocks when the channel is read or written outside of a go state machine)

there isn't a dispatch process

oh, I thought I’d seen this in my stack traces

the acting of publishing or consuming from a channel can cause things to be run on a threadpool

oh, so it is the channel driving it, like @xiongtx was saying? cool

yes

so there is no global process watching it all

right, now I see that thread-pool-executor names its threads async-dispatcher-%d for N threads

I misinterpreted those in my stack traces

which is why go blocks aren't gc roots

ahh, they can get gc’d if the relevant channels are gc’d? - it’s starting to make more sense now I think

yep

@noisesmith The point is that it’s cooperative multithreading; there’s no scheduler involved. This also means that the runtime cannot help you when you perform IO in a go block. Eli Bendersky has a great piece on this: https://eli.thegreenplace.net/2017/clojure-concurrency-and-blocking-with-coreasync/

@xiongtx I wasn’t imagining a preemptive scheduler, I was imagining a book-keeper that figured out which parked things were able to run

but of course the channels are fully qualified to do that, so there’s no need for such a book-keeper

regarding gc roots, a gc root is data that the gc can’t claim implicitly - for example if you have cyclical object references that contains no path to a root, all objects in that cycle qualify for gc

but if they are accessible from a root they remain alive

I understand that part…I guess the point is that since there’s no “book-keeper” for the go blocks they’re not reachable from any GC root?