Fork me on GitHub
Ben Sless14:08:13

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

Ben Sless14:08:26

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

Ben Sless17:08:07

Ah, I see now, thanks 🙂

Alex Miller (Clojure team)17:08:25

let and loop stuff are called local bindings

Ben Sless18:08:31

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

Ben Sless19:08:37

if for example I'd write something like:

(let [x 1] (future 1))

Alex Miller (Clojure team)19:08:50

do you mean (future x) ?

Alex Miller (Clojure team)19:08:30

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

Ben Sless19:08:51

That answers my questions regarding bindings. Around a year ago you 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

Alex Miller (Clojure team)19:08:46

I don't think anything has changed since that response

Alex Miller (Clojure team)19:08:06

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

Alex Miller (Clojure team)19:08:17

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

Alex Miller (Clojure team)19:08:15

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

Alex Miller (Clojure team)19:08:38

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

Ben Sless19:08:10

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.

Alex Miller (Clojure team)19:08:21

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

Alex Miller (Clojure team)19:08:03

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

Ben Sless19:08:37

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

Ben Sless19:08:39

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 🙏

Alex Miller (Clojure team)20:08:05

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)

Ben Sless14:08:26

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?