Fork me on GitHub
Daniel Craig14:06:40

Is there any way to get like a thread id inside a go block? I'd like to demo the fact that using a go block gives you access to a pool of threads


(.getId (Thread/currentThread))


this will show one of the threads used to "schedule" go blocks, I am not sure it demonstrates the "availability" of a real thread pool in that sense


since you're not supposed to run (in the IO sense) anything on these


but maybe you already know about all this

Daniel Craig14:06:20

I don't think this is what I'm looking for but I'm a little new to core.async


why don't you close-over a thread id when launching the go blocks?

Daniel Craig14:06:07

Like wrapping the go block in a let?

Daniel Craig14:06:37

Wouldn't all my go block threads then share the same 'thread id'?

Daniel Craig14:06:55

I'm sure I'm wrong

Daniel Craig14:06:05

Just wanted to ask the question šŸ™‚


(let [launch (fn [id] (async/go ....))]
  (mapv launch (range 50)))


or some variation thereof

Daniel Craig14:06:39

I want to keep my presentation really simple because I'm pitching Clojure and Core.async to my team at work, so I don't want to do anything too clever. This would be hard to explain


can you explain with words what your ideal demo would demonstrate? ie, "using a go block gives you access to a pool of threads"


(err, not ie, but explain more that phrase. sorry šŸ™‚

Daniel Craig15:06:34

I'd like to demonstrate that when you queue your writes to the cloud graph database using a core async channel, and then consume and execute them in a go block, the writing happens faster because it's done by a pool of threads

Daniel Craig15:06:21

I'd like to demonstrate that the pool of threads really does exist without any more code than a naked go block


go blocks will only schedule operations on channels (and return one), they will not spin threads for IO by magic (like in golang)


stuff you do inside of them might use a threadpool, or async/thread or wait on other go blocks return value (a chan) etc, but there's no threadpool involved other that the one used by the go block implementation, which you shouldn't rely on


(in short)


that's a common misconception that go blocks are lightweight threads, it's not really the same


it depends on your definition of that I guess


i treat core.async as almost exclusively a coordination library. it's for communication. but i think you could demonstrate how easy pipeline-blocking could be adapted here.


yeah good point


pipeline-* is a good thing to show off

Daniel Craig15:06:18

how did I miss pipeline-blocking, I read the api docs šŸ˜†


making a pitch for something is harder when you're less familiar with it


can work against causes


i'd be prepared for the question "why not some concurrent queue and a fixed thread threadpool pulling from the queue?"

Alex Miller (Clojure team)15:06:25

ie, an executor - and that is sufficient in a lot of cases. channels give you a bit better composability and features like transducers on the channel, alt (select) which is simply unavailable in Java, and things like the pipeline fns


I adore core.async for its intended use (coordination between concurrent processes) but I've found that with most PRs that introduce core.async: ā€¢ don't actually solve the problem at hand ā€¢ misunderstand the purpose of core.async and use it incorrectly in a way that will not show up in tests / dev envs ā€¢ could have been much simpler as an executor and a queue or just a few calls to future


I include my own first usages of core.async here, I totally ruined an app by adding core.async code that failed in a way that didn't show up until the system was under load


if I was paranoid I'd suggest that core.async was a conspiracy by core.async consultants to get contracts šŸ˜†


Does such a thing exist?


I worded it for humor / hyperbole, but specifically Timothy Baldridge has a talk where he shares the kinds of fix he ends up making in core.async code while contracting.

Alex Miller (Clojure team)15:06:07

I can assure you that's not the case :)


I know you are developing the lib in good faith. It's like the light saber hanging on the display stand - it attracts attention because it's so cool, but most of the time that eagerness to use it just ends in tragedy


but when used for what it's meant for, it's the greatest

Daniel Craig15:06:39

I think I'll delete the part of my demo about writing to the DB and simply show my team what I do have, which is Java interop. If I don't know this tool well enough, then it's not the right time to pitch it at work


advocate for benefits you have already felt and go with it

Daniel Craig15:06:32

Yeah I like that