According to https://clojure.org/dev/contrib_libs core.async is actively maintained by Rich but it feels like it's not getting much "love" and there are numerous patches that have been sat in the queue there for years. Is that a Contrib library that could reasonably be maintained more actively by one or more community members, or is it considered too close to "core" usage by various projects to be maintained outside of the Clojure core team?

(I ask because we've just switched at work to our own fork so we can get some of the patches applied and use that updated version in our production code)

We are going to continue managing that one

I'd be happy to hear more about what patches you're applying or finding to be important outstanding issues for you

I do spend time on it, just in periodic slices

@hiredman Do you want to talk about ASYNC-234 which we've applied in the fork we're using at work now, and some of the other patches you submitted ages ago that you'd like reviewed/applied?

I think it's unlikely that async-234's nack patches is something we're going to do

I was also forced to apply that patch to keep a service operational (only part 1, though)

our fork is just the 0001 patch

ok, good to know

if that's causing a lot of pain, I'm happy to raise it up the priority list and try to look at it in the near future

the 0001 patch is very conservative, but should help, but I still think core.async needs some kind of general resource cleanup mechanism (the nack stuff)

I'm curious if anyone has thought about alternate timer impls

I'm late for a meeting but if there are other things of similar priority, happy to hear about it

well, the nack patches include an alternative timeout impl, and I think I have a patch on another ticket in the jira that changes timeout to just return a ReadPort instead of a full channel

I have a toy alternative to core.async (that incudes a nack mechanism and follows the concurrent ml model more) that includes a timeout implementation (all the clean up of which is handled by the built in nack mechanism)

so I have thought a little bit about timeouts

but I think the focus on "timeouts" is incorrect, the 0001 patch for example doesn't touch timeouts at all

the issue alts attaches callbacks to whatever, and then has no way to notify whatever it attached callbacks to that the callbacks are no good any more, so the callbacks can hang around until whatever goes through all backs and checks the flag on them

outside of async-234 there is https://clojure.atlassian.net/browse/ASYNC-247 which you asked for a hand with

and there is also https://clojure.atlassian.net/browse/ASYNC-90

https://clojure.atlassian.net/browse/ASYNC-109 is the change to make timeout return a readport

for the nack stuff, some more precise feedback would be nice, like is some kind of nacking mechanism at all a non-starter, or is it a problem with the implementation

for my toy library I've got some stuff with watches on atoms, which might be a good basis for a lighter version of nacks (if I recall the handler for alts has an atom in it somewhere)

just from prior conversations with Rich, I suspect that's not a solution he's going to like very much

so the idea of nacks, not the impl

that is unfortunate

Well, we'll just have to continue with our fork of core.async then -- and perhaps we'll look at alternative implementations, at least for the JVM which is really all we care about. I'd love to see a near drop-in replacement for core.async based on virtual threads for example (and we're about to go from JDK 18 to JDK 19 at work so that's a realistic possibility in some ways).

Rich is definitely interested in that (which at some point makes some of these issues a moot point)

But not interested in someone outside of core building it and then contributing it, I assume?

it's not a matter of interest but rather that it's hard to come backwards from a big giant solution to the problems being addressed

like if someone rewrote most of next.jdbc and offered it to you, I think you would be reticent to just merge that, even if it was a change you were already considering

Are there any design docs around that would provide insight into what a vthread-powered core.async should look like? Or is this just an idea in Rich's head at the moment? Yeah, we don't want to do the work and then get it turned down, only to have Rich build something similar within core/Contrib.

Would love to talk with Rich about this...

just idle water cooler level chatter

OK, well, let him know that we're seriously interested in it -- if he is interested and has bandwidth to discuss in more detail.

noted

something I have been working on in async (really this dates back a couple years to work from Ghadi) is https://clojure.atlassian.net/browse/ASYNC-248 which I'm hoping to get merged this week pending review from Rich

@seancorfield @hiredman I think you should be able to see this filter https://clojure.atlassian.net/issues/?filter=10035 which is a prioritized list of open core.async issues that I work from

Yeah, with four assigned to @hiredman 🙂

everything you mentioned above is near the top of that already

well I don't really look at that :)

I mean I don't look at assignments, I do use this report :)

I know, just pointing out that a lot of past activism on some of those top issues has come from my colleague 🙂

I am aware :) and I appreciate the help