Clojurians Log v2

What's the reason for using (clojure.lang.Var/resetThreadBindingFrame binds) in thread-call? is it because threads are cached?

it's to convey bindings from the caller to the thread

same thing happens in future

by convey bindings you mean everything in let, loop, etc?

I'm asking because I got curious and started playing around with Loom

I vaguely remember seeing a library that provides buffers that issue warnings when they get full. Anyone know of something like this?

Ah, I see now, thanks 🙂

let and loop stuff are called local bindings

And those are compiled as private members of the fn instance in future/thread-call?

"those" == ?

if for example I'd write something like:

(let [x 1] (future 1))

do you mean (future x) ?

future generates a function that closes over locals, and those will be private members of the class emitted for that function

yes, my bad

That answers my questions regarding bindings. Around a year ago you https://ask.clojure.org/index.php/8196/any-plans-for-core-async-with-project-loom?show=8199#a8199 there are no plans regarding Loom at the moment. Has there been any change, since? I heard a talk by Ron Pressler recently where he mentioned they plan on adding channels in the future. It will be some more time before Loom makes it out of preview, but it will happen, eventually. In a broader scope, I'm wondering if and how the Clojure dev team will adjust to the changes Oracle has decided to make with regards to release schedules and features. Any light you can shed on that would be appreciated

I don't think anything has changed since that response

but maybe there has been some change to release schedule of Loom that I'm unaware of

oh, that's a shorter response - I wrote something longer somewhere else that I thought that was linking to

can't find that now, but I think reimplementing the core.async go block impl to leverage Loom would be an interesting exercise, but we'd want to do it because we believe it solves some problem and I don't know that that is well defined right now

but I do not expect to look at it until Loom is an LTS version of Java

I think it might make it as a 2nd preview feature to java 17 (If I remember Ron's presentation correctly), so there's some time.

I think the next LTS is going to be 17 and last I checked Loom was on track to make that

but again the question is - what problem will moving to Loom solve?

I can look at it from two directions: One, it will probably perform better than go blocks (performance is always nice) Two, currently, my understanding is that it's a bad idea to perform blocking IO inside go blocks. The thread pool is limited and can be exhausted, and real threads should be used. With virtual threads you can spawn as many as you'd like and block them (almost) whenever you'd like. It's true that loom doesn't solve a problem which isn't already solved by core.async, but I think it might end up being a simpler solution

It's getting late here and I find it harder to ask coherent questions, so I think I'll give you a break from my annoying questions for now. Thank you for all the explanations 🙏

I think the i/o thing is the more interesting problem here - due to what go blocks are used for, I don't think perf is particularly an issue right now. but this is what we would want to use to motivate the work. I think simplifying the code, particularly the go macro which duplicates a subset of the clojure analyzer would be vastly simpler and improve the core.async load time (when uncompiled)