Clojurians Log v2

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

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?

Like wrapping the go block in a let?

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

I'm sure I'm wrong

Just wanted to ask the question 🙂

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

or some variation thereof

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 🙂

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

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)

ohhhh

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

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

you said it

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

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 😆

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

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

Yeah I like that

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.