Fork me on GitHub
Jakub Holý (HolyJak)07:08:06

Is there some tool, library, or approach that would help me discover that a core.async threads is "stuck" because my code broke the rule and did a blocking call?

Alex Miller (Clojure team)11:08:48

There’s a system property you can set that will complain if you do that


It will only check core.async blocking ops, if you do some blocking/slow io via other means that will go undetected


Maybe these checks could be added via instrumentation in dev mode, vertx has something like that, it will detect unusually slow ops in "async" context and warn

Alex Miller (Clojure team)12:08:30

I don’t think that’s something we’re going to add in core.async


> It will only check core.async blocking ops, if you do some blocking/slow io via other means that will go undetected Yes this is something that clj-kondo or Eastwood could detect one day. Neither of them are much concerned about the notion of side-effects nowadays... much less about blocking vs. non-blocking IO distinction


I have it in the horizon to start related work in Eastwood, but who knows how would that go


these admonitions will potentially go away when Project Loom lands


the whole go macro source->source compiler will not need to exist


Next q, is there an async/thread drop-in replacement that will accept a custom thread pool? The intent is in the spirit of following When using the asynchronous query execution handler, you should provide application-specific interceptors to rate limit requests, or risk saturating your server. per Nothing that one couldn't implement quickly but... you know


you can always make your own


you're right, it's pretty simple -- evaluate an expression, drop the result in a channel


Is Project Loom expected to land within the next year or two?




maybe 1 < n < 2


you can try it rn apparently


a fiber, even


@ghadi any idea how core-async would take advantage of Loom on new JDKs while remaining backwards compatible with non-Loom stuff? different artifacts?


completely unexplored. that being said, I don't see anything in the public API that precludes a different impl with the same semantics

Alex Miller (Clojure team)21:08:33

(that's a windows joke)


I mean, assuming countdownlatch works with virtual threads, then clojure.core/promise will work with virtual threads, then <!! will work fine with virtual threads, and no change is required, non-loom stuff will continue to use <!, and loom stuff can use <!!


no need to do anything