Clojurians Log v2
core-async
Why does the last >!! in this example never complete?
(require '[clojure.core.async :as async])
(def chan (async/chan 8))
(async/>!! chan :foo)
(async/<!! chan)
(future (async/<!! chan))
(future-cancel *1)
(async/>!! chan :bar) ; this put never completes
(count (.buf chan)) ;;=> 0
(async/<!! chan) ; blocks forever
your future call is still pending take!
so when you put :bar, it's consumed by that call
put another value, and you can take from it again
(future (a/<!! c))
(future-cancel *1)
(a/>!! c :foo)
(a/>!! c :bar)
(a/<!! c) ;; => :barHmm, right, thanks. So if I understand correctly, interrupting the thread doing the <!! aborts the take, but doesn't decrement the take counter of the channel, which is why core.async remains waiting for an additional put.
eh
conceptually okay, but not technically correct
when there is nothing in the channel to take, take handlers get put into a linked list. <!! then blocks on a promise waiting for its take to get called. what gets aborted is dereffing the promise. and yeah, interrupting a thread doesn't go back and remove that take from the linked list.
That's helpful, thanks! Now I understand. 👍
(And yeah, I began thinking in terms of counters because I was playing around with the new Datafiable support on channels, which have :take-count and :put-count. 🙂 )
I don't think <!! is interruptible even no? Or maybe the underlying blocking queue is?
CountDownLatch#awaitOk, so that would throw an InterruptedException
I wonder if there's a way to catch it inside the future and clear the take ?
I don't know of any way to clear a take outside of mucking with channel internals
I feel it seems a bit of a "bug" to me. Or at least an undefined behavior. Because you'd expect<!! to properly handle interrupt. And maybe this is the semantic they want, like it doesn't actually cancel but will get interrupted.
But probably something internally to core.async you could fix.
yeah the only place to fix it would be inside core.async. probably in <!! itself.
I agree that the behavior caught me off guard.
does anyone have examples of otel tracing with flow? i realize this is very early on but i am curious how to set it up to track execution across procs.
flow is pretty generic and doesn't necessarily presume a request-orientation
you can do all the ordinary things that you need to do to convey a logical request for otel: add a map key representing the otel context object, flow (verb) that around
Datomic's core update system is a flow (the noun) -- though it predates flow (the library) by 10+ years
we have some otel instrumentation for dev purposes, you do all the normal things to connect bindings across thread boundaries
awesome, ty! i will explore and share back any examples i can
shameless plug, but if it is for dev tracing purposes there is https://github.com/flow-storm/flow-storm-async-flow-plugin