core-async

Ben Sless 2020-08-13T14:07:13.134400Z

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

ghadi 2020-08-13T14:08:50.134800Z

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

ghadi 2020-08-13T14:08:57.135100Z

same thing happens in future

Ben Sless 2020-08-13T14:13:26.135500Z

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

Ben Sless 2020-08-13T14:16:26.135900Z

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

2020-08-13T14:24:39.136900Z

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

Ben Sless 2020-08-13T17:40:07.137700Z

Ah, I see now, thanks 🙂

alexmiller 2020-08-13T17:42:25.137900Z

let and loop stuff are called local bindings

Ben Sless 2020-08-13T18:11:31.138100Z

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

alexmiller 2020-08-13T18:49:34.138300Z

"those" == ?

Ben Sless 2020-08-13T19:02:37.138500Z

if for example I'd write something like:

(let [x 1] (future 1))

alexmiller 2020-08-13T19:07:50.138700Z

do you mean (future x) ?

alexmiller 2020-08-13T19:08:30.138900Z

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

Ben Sless 2020-08-13T19:12:21.139100Z

yes, my bad

Ben Sless 2020-08-13T19:19:51.139300Z

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

alexmiller 2020-08-13T19:21:46.139600Z

I don't think anything has changed since that response

alexmiller 2020-08-13T19:22:06.139800Z

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

alexmiller 2020-08-13T19:23:17.140100Z

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

alexmiller 2020-08-13T19:27:15.140300Z

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

alexmiller 2020-08-13T19:27:38.140500Z

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

Ben Sless 2020-08-13T19:30:10.140700Z

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.

alexmiller 2020-08-13T19:30:21.140900Z

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

alexmiller 2020-08-13T19:31:03.141100Z

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

Ben Sless 2020-08-13T19:39:37.141300Z

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 Sless 2020-08-13T19:41:39.141500Z

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 🙏

alexmiller 2020-08-13T20:02:05.141700Z

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)