Fork me on GitHub
#core-async
<
2021-08-27
>
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

mpenet12:08:37

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

mpenet12:08:29

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

vemv19:08:39

> 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

vemv19:08:41

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

ghadi19:08:57

these admonitions will potentially go away when Project Loom lands

ghadi19:08:01

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

vemv19:08:55

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 https://lacinia-pedestal.readthedocs.io/en/latest/async.html Nothing that one couldn't implement quickly but... you know

ghadi20:08:00

you can always make your own

ghadi20:08:39

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

borkdude20:08:15

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

borkdude20:08:52

exciiiiting

ghadi20:08:14

maybe 1 < n < 2

vemv20:08:14

you can try it rn apparently

vemv20:08:47

a fiber, even

schmee20:08:01

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

ghadi21:08:30

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)

hiredman21:08:37

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 <!!

hiredman21:08:55

no need to do anything