Clojure Q&A - Recent questions and answers in core.async

Answered: `flow/ping-proc` can be slow or fail to respond, even when process isn't busy

Wed, 28 Jan 2026 19:54:27 +0000

Thanks, we've been discussing ways to specify filters for proc state datafication.

Answered: flow monitoring tool serves resources from unqualified path

Mon, 24 Nov 2025 19:27:37 +0000

Resource path has been updated in v0.1.3

`pipeline-blocking` uses `thread` internally instead of `io-thread`

Wed, 29 Oct 2025 15:54:00 +0000

pipeline-blocking is explicitly meant for blocking operations (implying I/O). However, internally it uses thread rather than io-thread for processing: https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L637-L640.

Since 1.9.829-alpha2 this has practical implications, as only io-thread will utilize virtual threads, when available.

Can this be fixed / changed?
If not, can an explicit pipeline-io (or similar) function be added to support this use case?

Thanks

Choosing between core.async pipelines

Sun, 26 Oct 2025 22:19:12 +0000

It's no longer clear what kind of pipeline is suitable for what kind of task in core.async.

Previously, my understanding was that anything I/O-bound should go into pipeline-blocking, while CPU-bound tasks went into regular (i.e. :compute) pipeline. But a while back :compute pipelines were changed to use threads instead of go-blocks. And now, with the introduction of virtual threads, pipeline-async seems like the right choice for I/O-bound tasks.

It seems that workloads are being classified into one of three types: :compute, :io, and :mixed. Is :async meant to be the equivalent of :io, and :blocking the equivalent of :mixed? I don't think that's original semantics, but it seems to be the mapping now.

Answered: Replace core.async’s internal LinkedList queue with ArrayDeque?

Wed, 03 Sep 2025 20:10:39 +0000

There is a ticket for this at https://clojure.atlassian.net/browse/ASYNC-231

Answered: Typos in Flow guide

Mon, 18 Aug 2025 13:35:12 +0000

Already fixed, thx

Answered: Is core.async.flow available in ClojureScript?

Fri, 18 Jul 2025 19:10:40 +0000

No, we are not currently targeting it to ClojureScript as it's really intended for writing multi-threaded applications.

Answered: what kind of systems could be made with clojure.async.flow?

Tue, 29 Apr 2025 16:19:18 +0000

core.async.flow is particularly well suited to what Rich called "situated programs" in the "Effective Programs" talk https://www.youtube.com/watch?v=2V1FtfBDsLU . These programs execute for long periods of time (often continuously), deal with information, have extensive "memory" (via database connections), and interact with the real world via external I/O channels (these days, often messaging systems like Kafka etc).

You're correct that flow is a poor fit to run in a lambda or in a an RPC style web request path - you are probably better served in writing synchronous code for those scenarios and avoiding the setup and async overhead. But those kinds of processes often feed one or more situated programs via a message queue or database insert.

I would also recommend Rich's "Language of the System" talk which predates flow and core.async(!) by many years but is very much of this idea. https://www.youtube.com/watch?v=ROor6_NGIWU

core.async go block error with clojure 1.12 method values

Tue, 25 Feb 2025 19:17:23 +0000

I haven't seen this reported.

(Long/.toString 123) ;;works
(a/<!! (a/thread (Long/.toString 123))) ;;works
(a/go (Long/.toString 123)) ;;error

Note: The following stack trace applies to the reader or compiler, your code was not executed.

CompilerException Syntax error macroexpanding a/go at (1:1). {:clojure.error/phase :macro-syntax-check, :clojure.error/line 1, :clojure.error/column 1, :clojure.error/source "NO_SOURCE_PATH", :clojure.error/symbol a/go}
ExceptionInfo No matching method: .toString for class: class java.lang.Long and arity: 1 {:method .toString, :class java.lang.Long, :argc 1, :file "NO_SOURCE_PATH", :column 7, :line 1}
	clojure.tools.analyzer.passes.jvm.validate/validate-call (validate.clj:127)
	clojure.tools.analyzer.passes.jvm.validate/validate-call (validate.clj:87)
	clojure.tools.analyzer.passes.jvm.validate/eval4802/fn--4803 (validate.clj:137)
	clojure.lang.MultiFn.invoke (MultiFn.java:229)
	clojure.tools.analyzer.passes.jvm.validate/validate (validate.clj:265)
	clojure.tools.analyzer.passes.jvm.validate/validate (validate.clj:240)
	clojure.lang.Var.invoke (Var.java:386)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3429 (passes.clj:167)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.core/partial/fn--5929 (core.clj:2648)

Answered: The cljs docstring of `clojure.core.async/promise-chan` does not mention that it returns the value repeatedly

Thu, 29 Aug 2024 16:56:15 +0000

Thanks, an oversight. Fixed in core-async master now.

Answered: Why do core.async timeouts rely on non-monotonic system clock?

Thu, 02 Nov 2023 14:45:13 +0000

Small correction: On POSIX systems, OpenJDK uses clock_gettime with CLOCK_MONOTONIC for System/nanoTime which is subject to incremental adjustments as done e.g. by NTP. However, it does guarantee to never go backwards and it's not affected by discontinuous jumps (e.g. by manually setting the system time) That's in contrast to CLOCK_REALTIME which is used by System/currentTimeMillis there. See man 2 clock_gettime for details.

The discussion around JDK-8006942 has some insight into why such incremental adjustment might be desirable even for System/nanoTime:

Having been bitten by various time-jumping bugs in the past due to NTP (and other) adjustments, my initial reaction was that doing any kind of adjustment to CLOCK_MONOTONIC was "crazy" and obviously we should prefer the unadjusted CLOCK_MONOTONIC_RAW. However after looking into this more carefully I agree with Martin's comment that the NTP-slew that is applied is generally desirable to keep the reported elapsed times in-line with actual elapsed time. This slew simply adjusts the rate at which the reported time is updated to account for hardware that runs faster or slower than true time (which is pretty much all hardware). It does not introduce observable jumps in the time reported and should not be observable to the end user.

Answered: Virtual thread executor for core.async

Mon, 16 Oct 2023 11:12:34 +0000

Spindle monkey patches core.async to add this capability. Note: I’m not the author of this library, nor (yet) a user of it, though I greatly respect the author’s contributions to the Clojure ecosystem.

Answered: Fix for the ASYNC-163 - Off by two error in pipeline-async

Tue, 22 Nov 2022 18:38:36 +0000

Hello, the "won't fix" there is to indicate that we don't think this is a problem and don't think it needs to be fixed.

Answered: core.async readme oversight

Wed, 09 Nov 2022 14:35:27 +0000

Thanks, fixed!

Answered: core.async test hangs on single-cpu system

Wed, 06 Jul 2022 15:39:54 +0000

Logged as https://clojure.atlassian.net/browse/ASYNC-246

Answered: (CLJS) A local named `new` breaks go macro in cljs (not in clj)

Tue, 29 Jun 2021 00:59:26 +0000

I don't have an answer to this question. I was facing the same problem and did a bit of digging and thought I can share it here to help whoever is looking at this. I found that this issue is associated with creating cljs.core/PersistentVector. Here are my examples:

(require '[cljs.core.async :refer [go <! chan put!]])

(def c (chan))

(put! c {:hi "here"})

;; This fails
(go
  (let [{:keys [new] :as msg} (<! c)]
    (js/console.log [:msg-received msg])))
;; ioc_helpers.cljs:50 Uncaught TypeError: inst_25288.call is not a function
;; at switch__20329__auto__ (eval at figwheel$repl$eval_javascript_STAR__STAR_ (repl.cljc:364), <anonymous>:86:29)
;; at eval (eval at figwheel$repl$eval_javascript_STAR__STAR_ (repl.cljc:364), <anonymous>:166:51)
;; at mini_reframe$app$state_machine__20330__auto____1 (eval at figwheel$repl$eval_javascript_STAR__STAR_ (repl.cljc:364), <anonymous>:188:4)
;; at mini_reframe$app$state_machine__20330__auto__ (eval at figwheel$repl$eval_javascript_STAR__STAR_ (repl.cljc:364), <anonymous>:204:57)
;; at cljs$core$async$impl$ioc_helpers$run_state_machine (ioc_helpers.cljs:43)
;; at cljs$core$async$impl$ioc_helpers$run_state_machine_wrapped (ioc_helpers.cljs:47)
;; at eval (eval at figwheel$repl$eval_javascript_STAR__STAR_ (repl.cljc:364), <anonymous>:218:67)
;; at cljs$core$async$impl$dispatch$process_messages (dispatch.cljs:27)
;; at MessagePort.channel.port1.onmessage (nexttick.js:218)

(put! c {:hi "here"})

;; All the below cases work
(go
  (let [{:keys [a] :as msg} (<! c)]
    (js/console.log [:msg-received msg])))
;; [:msg-received {:hi "here"}]

(put! c {:hi "here"})

(go
  (let [msg (<! c)]
    (js/console.log [:msg-received msg])))
;; [:msg-received {:hi "here"}]

(put! c {:hi "here"})

(go
  (let [{:keys [new] :as msg} (<! c)]
    (js/console.log msg)))
;; {:hi "here"}

(put! c {:hi "here"})

(defn receive-msg [msg]
  (js/console.log [:msg-received msg]))

(go
  (let [{:keys [new] :as msg} (<! c)]
    (receive-msg msg)))
;; [:msg-received {:hi "here"}]

When I compare at the macroexpand-1 results, I found that in the failure case, the let-binding for new seems to be shadowing the JS new keyword, see the inst_23688 symbol before cljs.core/PersistentVector:

  (macroexpand-1
    '(go
       (let [{:keys [new] :as msg} (<! c)]
         (js/console.log [:msg-received msg]))))
  => ...
      (clojure.core/let
           [inst_23687
            (clojure.core/aget state_23694 2)
            inst_23688
            (cljs.core/get inst_23687 :new)
            inst_23689
            (. cljs.core/PersistentVector -EMPTY-NODE)
            inst_23690
            (js* "[~{},~{}]" :msg-received inst_23687)
            inst_23691
            (inst_23688
             cljs.core/PersistentVector
             nil
             2
             5
             inst_23689
             inst_23690
             nil)
            inst_23692
            (js/console.log inst_23691)
            state_23694
            state_23694]
           (cljs.core.async.impl.ioc-helpers/return-chan
            state_23694
            inst_23692))

Whereas in the successful case, there's the plain new JS keyword before the cljs.core/PersistentVector:

  (macroexpand-1
    '(go
       (let [{:keys [a] :as msg} (<! c)]
         (js/console.log [:msg-received msg]))))
=> ...
(clojure.core/let
           [inst_24256
            (clojure.core/aget state_24263 2)
            inst_24257
            (cljs.core/get inst_24256 :a)
            inst_24258
            (. cljs.core/PersistentVector -EMPTY-NODE)
            inst_24259
            (js* "[~{},~{}]" :msg-received inst_24256)
            inst_24260
            (new cljs.core/PersistentVector nil 2 5 inst_24258 inst_24259 nil)
            inst_24261
            (js/console.log inst_24260)
            state_24263
            (cljs.core.async.impl.ioc-macros/aset-all!
             state_24263
             8
             inst_24257)]
           (cljs.core.async.impl.ioc-helpers/return-chan
            state_24263
            inst_24261))

Answered: Easy to hang the current thread with `(a/
Mon, 24 May 2021 16:12:14 +0000

Logged as https://clojure.atlassian.net/browse/ASYNC-238

Answered: Strategies for diagnosing core.async code that is unexpectedly blocking the main thread?

Sun, 14 Feb 2021 22:11:02 +0000

(1) The producer half of the 2nd test puts 2, the consumer (reading evens) reads 2; the producer puts 1, but the consumer isn't consuming odds yet, so the producer waits, and from the consumer's point of view the channel of evens "never closes", so the consumer sticks at the first <!!.

(2) The hang is the best problem to have because you can insert prints and figure out what's hanging. Sub-optimal balance is harder to get clarity on.

(3) The simpler, the better.

Answered: How to do a blocking put on a channel ?

Tue, 08 Dec 2020 20:06:37 +0000

It's not clear to me how you could get that error from that code. Could you post either the real code or a standalone example that reproduces the problem?

Answered: documentation issues on clojurescript promises interop

Fri, 18 Sep 2020 02:57:07 +0000

can you explain what issue you are running into? What does exposed as a function mean?

/t/async ❯❯❯ clj -A:cljs:async -m cljs.main -re node -r
ClojureScript 1.10.773
cljs.user=> (require '[clojure.core.async :as a :refer [go]])
nil
cljs.user=> (doc go)
-------------------------
cljs.core.async/go
([& body])
Macro
  Asynchronously executes the body, returning immediately to the
  calling thread. Additionally, any visible calls to <!, >! and alt!/alts!
  channel operations within the body will block (if necessary) by
  'parking' the calling thread rather than tying up an OS thread (or
  the only JS thread when in ClojureScript). Upon completion of the
  operation, the body will be resumed.

  Returns a channel which will receive the result of the body when
  completed

nil
cljs.user=>(let [x (go 3)] (go (prn (a/<! x))))
#object[cljs.core.async.impl.channels.ManyToManyChannel]
cljs.user=> 3

Moreover, this should be fine.

macros can be referred in this way: https://www.clojurescript.org/about/differences#_namespaces
go is defined as a macro: https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async.clj#L12
go is referred as a macro from async.cljs: https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async.cljs#L19

relevant part from above:
> Implicit macro loading: If a namespace is required or used, and that namespace itself requires or uses macros from its own namespace, then the macros will be implicitly required or used using the same specifications. Furthermore, in this case, macro vars may be included in a :refer or :only spec. This oftentimes leads to simplified library usage, such that the consuming namespace need not be concerned about explicitly distinguishing between whether certain vars are functions or macros. For example:

Answered: (CLJS) finally-block prevents exception throw in go-block

Mon, 07 Sep 2020 16:21:16 +0000

One line reproduce:
clojure -Srepro -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.520"} org.clojure/core.async {:mvn/version "1.3.610"}}}' -m cljs.main -re node -e "(require '[clojure.core.async :refer [go]]) (go (try (try (throw (ex-info "err" {:ex 42})) (catch js/Error e (throw e)) (finally (prn :finally))) (catch js/Error e (prn :catch2))))"

I tested with {clj,cljs} x {with-go,without-go} and it only work on cljs with go

Answered: Add additional arity to the ex-handler [core.async]

Mon, 20 Apr 2020 23:02:34 +0000

This is a duplicate of an existing question/ticket:

Answered: Add support for
Tue, 24 Mar 2020 20:37:11 +0000

You can use poll! and offer! instead, they are the non-blocking equivalent. Just keep in mind, they will not "wait" for a value to be available, so you need to keep polling yourself, or be sure there should be one.

Like others have said, `<!!` doesn't make sense in the context of JavaScript, since you never want to block the main thread, and it would need too in order to perform the "waiting" operation.

There also exists take!, if you don't want to implement polling yourself, it will do it for you (well more efficiently), and call you back when the value is available with it.

Answered: core.async bug: "No more than 1024 pending takes are allowed" assertion involving 'alt!'

Sun, 09 Feb 2020 03:55:06 +0000

Dear Mr. Sperber,

i do not think i understand the problem very well. (... also... and tbh i have not really spent much thought on this :-).... )

Having said that, i just ran:

(ns asyncbug.core
  (:gen-class)
  (:require [clojure.core.async :as async]))


(defn -main
  "I don't do a whole lot ... yet."
  [& args]

  (dotimes [n 5000]
    (comment "
- start 1024 threads that all alt! on a common channel (ch) and
  on an individual channel (x)
- the common channel remains 'empty' all the time
- wakeup all theads twice via the x channel, which makes them loop.
- this quickly raises multiple
  'No more than 1024 pending takes are allowed on a single channel.'
  assertions in an async-dispatch thread.
")
    (let [ch (async/chan)

          threads clojure.core.async.impl.protocols/MAX-QUEUE-SIZE
          wakeups 2
          x-chans
          (mapv (fn [n]
                  (let [x (async/chan)]
                    (async/go-loop []
                      (async/alt!
                        ch nil
                        x ([_] (recur))))
                    x))
                (range threads))]
      (doseq [x x-chans]
        (dotimes [n wakeups]
          (async/>!! x 42)))
      (async/close! ch))

    (println "iteration: " n))

  (println "Hello, World!"))

(defproject asyncbug "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
            :url "https://www.eclipse.org/legal/epl-2.0/"}
  :dependencies [[org.clojure/clojure "1.10.0"]
                 [org.clojure/core.async "0.7.559"]]
  :main ^:skip-aot asyncbug.core
  :target-path "target/%s"
  :profiles {:uberjar {:aot :all}})

java -version
openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1)
OpenJDK 64-Bit Server VM (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1, mixed mode, sharing)

which eventually yields the "Hello, World!".

again.... i am really not quite sure about what is ( supposed to be ) going on here.... so i may be doing this all wrong :-)....

i have also given this a quick go using the core-async 0.6.532 version you mentioned, but aborted after 32 successful iterations..... until then no AssertionError had been raised.

i am sorry i could not be of more help to you.

Best Regards,
Florian Tauber

Answered: A literal meta in cljs.core.async

Sat, 28 Dec 2019 08:49:18 +0000

Answered: core.async pipeline arguments order

Thu, 26 Dec 2019 14:09:18 +0000

Iirc, the idea was to match into.

Answered: where is the blocking operation?

Fri, 08 Nov 2019 19:15:33 +0000

As a general policy, blocking operations should not be performed in the scope of a go block, and that includes the core.async blocking operations like >!!. So, yes - the problem here is that the pipeline code violates this policy. In practice, you're correct in this particular case that using >!! on an empty channel of size 1 won't block (but it still violates the policy of intent).

Using put! would be another option, however there is also a bigger conceptual issue here that pipeline purports to use "parallelism n". However, by putting those tasks in go blocks, you are actually subject to a max parallelism of the go thread pool, which is typically 8, and that presumes no one else is using the go block thread pool, so it could even be less than that. And secondly, if the user happens to do a blocking operation in pipeline (which they shouldn't), then they can easily lock up the whole system.

Switching to use the same strategy as pipeline-blocking (using a separate caching thread pool) addresses the parallelism issue. However, this may not be the last change in this regard - we may still switch to use an explicit fixed size compute thread pool, rather than a caching thread pool which would separate these again. So, no plans to deprecate anything - the user is still stating an intent that makes an important difference here.

Answered: Is alt!! actually not completing put operations when the channel closes?

Tue, 17 Sep 2019 12:45:50 +0000

Can you give an example?

Answered: Any plans for core.async with Project Loom?

Fri, 26 Jul 2019 13:16:25 +0000

No plans right now, seems fairly speculative still.

Answered: `
Wed, 26 Jun 2019 12:00:00 +0000
Reference: https://clojure.atlassian.net/browse/ASYNC-161 (reported by johanatan)

Answered: mult distribution behavior doesn't work as intended