Clojure Q&A - Recent questions in core.async

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

Wed, 28 Jan 2026 18:01:40 +0000

I've run into a few cases where flow/ping and flow/ping-proc are slow and timeout.

I was able to track the issue down to this line https://github.com/clojure/core.async/blob/b871f3519de6843a9f5ce66cf8d5c6cbe44d3222/src/main/clojure/clojure/core/async/flow/impl.clj#L273

(async/>!! c
            (walk/postwalk datafy
                           #::flow{:pid pid, :status status
                                   :state state,
                                   :count count
                                   :ins pins :outs pouts}))

This causes the state of the flow process to be traversed and datafied.

In one case, I had some process state that threw an exception when datafied due to an incomplete datafy extension. This caused flow/ping-proc to silently fail. No errors were reported.

In some other cases, the flow processes were working with large values. Walking the process state was slow and caused pings to respond slowly.

flow monitoring tool serves resources from unqualified path

Tue, 04 Nov 2025 20:57:47 +0000

For flow monitoring, HTML, CSS, and javascript assets are served from the resource path "public/". If there is another library on the classpath that also has a resource at "public/index.html", then flow monitoring's assets will get clobbered and serve the wrong web page instead. Alternatively, flow monitoring may clobber someone else's resources.

https://github.com/clojure/core.async.flow-monitor/blob/6248a5d8e4228ab5974289559e3cb11ff3152263/src/clojure/core/async/flow_monitor.clj#L104

This can be addressed by moving resources to a qualified path like "clojure/core/async/flow_monitor/public/index.html".

`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.

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

Tue, 02 Sep 2025 08:02:18 +0000

Hi! While reading the channel implementation I noticed the internal queue is a java.util.LinkedList:
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj

The common JVM guidance these days is to prefer java.util.ArrayDeque for FIFO/LIFO queues due to better locality and lower GC overhead. For example, the JDK docs state: “This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue.”
https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html
Related SO discussion: https://stackoverflow.com/questions/6163166/why-is-arraydeque-better-than-linkedlist

A few questions for the maintainers:

Was LinkedList originally chosen for a specific reason (e.g., very old JDK compatibility)?
Are there behaviors in channels that specifically rely on LinkedList (e.g., allowing null, I believe channels disallow nil anyway, or particular iterator characteristics), or would ArrayDeque be a drop-in replacement for the add/remove-from-ends operations used?
If we provide a small PR and benchmark showing an improvement (lower allocations / better throughput under contention), would such a change be considered?
Since ArrayDeque is available on Java 8+, and current Clojure/core.async baselines target that or newer, is there any remaining compatibility concern?

Context: there was an older conversation in Clojurians (#clojure) that suggested ArrayDeque could reduce GC pressure under load and that the original choice may have been influenced by older JDKs:
https://clojurians.slack.com/archives/C03S1KBA2/p1526551888000376

If this sounds reasonable, I’m happy to run the core.async test suite, add JMH-style benchmarks focused on channel put/take hot paths, and submit a PR.

Thanks!

Typos in Flow guide

Mon, 18 Aug 2025 08:19:35 +0000

As reported by a Hacker News user, there are typos in the Flow Guide :

"excepiton" should be "exception"
"provded" should be "provided"

and also, it seems that in the transition section, "The description arity takes the current state ..." should be "The transition arity takes the current state ..."

Is core.async.flow available in ClojureScript?

Thu, 17 Jul 2025 08:31:10 +0000

Hi,

I know it's early days for core.async.flow but I thought I would give it a try in one of my ClojureScript projects.

I've got {:mvn/version "1.9.808-alpha1"} in my deps.edn but I'm getting the following error when I try to access the namespace:

No such namespace: clojure.core.async.flow, could not locate clojure/core/async/flow.cljs

Thanks for your help.

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

Tue, 29 Apr 2025 15:48:35 +0000

Trying to capture mechanical essence of clojure.async.flow with basic terms instead of flow own terms i guess that clojure.async.flow allows to structure a system as a set of stateful functions running concurrently in the same jvm process and interacting with each other explicitly via channels.

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

it's definitely not naive service which handles API http requests, transforms it somehow and puts it into database.

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)

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

Tue, 27 Aug 2024 16:28:38 +0000

Question in slack about why a promise chan "returns the result of the promise every time you call".

The docstring in clj includes the phrase

Consumers will block until either a value is placed in the channel or the
channel is closed, then return the value (or nil) forever.

This is missing from the clojurescript version of the docstring:

Creates a promise channel with an optional transducer, and an optional
exception-handler. A promise channel can take exactly one value that consumers
will receive. Once full, puts complete but val is dropped (no transfer).
Consumers will block until either a value is placed in the channel or the
channel is closed. See chan for the semantics of xform and ex-handler.

source

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

Wed, 01 Nov 2023 16:26:33 +0000

clojure.core.async/timeout uses System/currentTimeMillis to calculate its deadline (see here and here). While the docstring for System/currentTimeMillis doesn't mention it explicitly, it's quite clearly unsuitable for this purpose because it returns the current time as reported by the OS. Since that time can change arbitrarily (e.g. by correction via NTP), the deadline calculations may end up inconsistent. This behavior is very much intended, see e.g. this ticket where it was suggested to switch System/currentTimeMillis over to a monotonic clock where possible. It was refused with the following comment:

System.currentTimeMillis() is required to return milliseconds since the epoch and should reflect external changes to the system/wall-clock time. CLOCK_MONOTONIC_COARSE does not provide that and so can not be used for this purpose.

Also, the docstring for java.util.concurrent.ScheduledExecutorService states this quite plainly:

All schedule methods accept relative delays and periods as arguments, not absolute times or dates. It is a simple matter to transform an absolute time represented as a Date to the required form. For example, to schedule at a certain future date, you can use: schedule(task, date.getTime() - System.currentTimeMillis(), TimeUnit.MILLISECONDS). Beware however that expiration of a relative delay need not coincide with the current Date at which the task is enabled due to network time synchronization protocols, clock drift, or other factors.

Since all we care about here is deltas, it seems advisable to switch to System/nanoTime instead. Unfortunately, its docstring also doesn't make its properties very obvious. It doesn't mention that it's a monotonic clock but only hints at it by stating:

Returns the current value of the running Java Virtual Machine's high-resolution time source, in nanoseconds. This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. [...] The values returned by this method become meaningful only when the difference between two such values, obtained within the same instance of a Java virtual machine, is computed.

A case in point for using it is OpenJDK's implementation of java.util.concurrent.ScheduledThreadPoolExecutor whose deadline calculation method does so, as well as its getDelay implementation.

Furthermore--if it's anything to go by--various StackOverflow posts also discuss this and arrive at the same conclusion, e.g. this one:

Nonetheless, nanoTime() should still be preferred for implementing timed blocking, interval waiting, timeouts, etc. to currentTimeMillis() because the latter is a subject to the "time going backward" phenomenon (e. g. due to server time correction), i. e. currentTimeMillis() is not suitable for measuring time intervals at all. See this answer for more information.

Virtual thread executor for core.async

Sun, 08 Oct 2023 23:30:28 +0000

There have been a few people on Slack asking about virtual threads and core.async before. Here is an example of one such thread https://clojurians.slack.com/archives/C05423W6H/p1677676131782299

Of course, consideration is also needed for ClojureScript and non-Loom code. I would assume a virtual thread aware implementation of core.async would probably exist in a dedicated namespace to prevent breaking old code.

I am posting this question both as a feature request and a central place for people to vote.

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

Tue, 22 Nov 2022 17:48:51 +0000

Hello!

I've been working on a fix for the ASYNC-163 bug, and I think I've got a robust solution that doesn't require many changes to the pipeline* function.

I'm new to contributing to Clojure, so I'm a bit unsure about the process, though I've read about it on the clojure.org website. There's already an existing ticket for the problem, which I've linked above, however, it was closed as "won't fix", and I don't have a Jira account to comment there and send a patch, so I've decided to post here.

After studying the source code of the pipeline* function, I've understood the whole process of how jobs are passed between go-threads and channels and found a simple fix, that requires adding one more channel to synchronize job-producer and result-consumer threads.
I have a more in-depth explanation of the bug in my blog. It is rather long and convoluted, so I think it would be best if I will not repeat myself here, making this question unnecessarily long and much harder to understand. The explanation is available here.

I'm attaching a patch here, feel free to point me in the right direction if this place is not for this type of question. I've tested the in the REPL with various scenarios and in one of my projects, that uses regular pipeline-async, it works correctly. In addition, it passes tests in the core.async library, which I ran with the lein test command.

Patch: https://andreyorst.gitlab.io/0001-fix-ASYNC-163.patch

At the moment I have some problems with running CLJS tests with or without my patch for the async.cljs file, but once I figure out the problem I'll post an updated patch, for both JVM and CLJS runtimes

Edit: Nov 25 2022

Patch v2: https://andreyorst.gitlab.io/0001-fix-ASYNC-163-2.patch

This patch includes the same fix for async.cljs, though I wasn't able to run tests for some reason - I get the Uncaught TypeError: process.on is not a function error in the browser. Not sure what I'm missing, the project's readme doesn't mention any requirements besides building with lein and opening the HTML file. But the fix is essentially the same, so it should work fine.

Edit Dec 08 2022

I've put the fixed version of pipeline* into a library pipeline-extras. It also has unordered versions of all pipelines, which should have higher throughput because the conveyer doesn't stop if any of the tasks take longer to complete than the other ones.

core.async readme oversight

Wed, 09 Nov 2022 10:55:02 +0000

https://github.com/clojure/core.async/blob/96cb49e15b046e17e5b73eee5f9ce61ab44883ba/README.md?plain=true#L17 refers to 1.5, while the latest at the moment is 1.6

core.async test hangs on single-cpu system

Wed, 06 Jul 2022 14:09:21 +0000

When running the core.async testsuite on a single-cpu system, the tests hang at the ASYNC-127 test.

I noticed this when attempting to run the tests on the Debian package building infrastructure and was also able to reproduce the issue locally.

Our current workaround is to simply skip that test altogether.

Easy to hang the current thread with `(a/

Mon, 24 May 2021 16:09:20 +0000

This code

(a/<!! (a/map vector []))

will hang the current thread.

Would be nice if there was a check for the empty chs argument to a/map or at least a docstring mention, given how easy it is to fall into this trap by using e.g. filter in place of the [] above.

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

Sun, 14 Feb 2021 21:07:06 +0000

I'm new to core.async (and CSP more generally) and struggling to find good debugging strategies. In particular, I frequently fail to diagnosis which part of the code is infinitely blocking the main thread. I'll give a particular example:

(deftest passing-test
  (let [c (async/to-chan! [2 1 0 5 4])]
    (is (= [2 1 0 5 4]
           (async/<!! (async/into [] c))))))


(deftest hanging-test
  (let [[e o] (->> (async/to-chan! [2 1 0 5 4])
                   (async/split even?))]
    (is (= [2 0 4]
           (async/<!! (async/into [] e))))
    (is (= [1 5]
           (async/<!! (async/into [] o))))))

The first test passes and does not block the main thread. The second test hangs forever. The only difference is the addition of async/split to route even and odd integers to their respective channels.

My specific questions are as follows:

What explains the difference between the first and second tests with respect to blocking the main thread?
What are some strategies to debugging core.async code that is unexpectedly blocking the main thread?
What is the best way to write unit tests for code that creates and manipulates channels? Is (async/<!! (async/into [] o)) a reasonable way to collect the values flowing through a channel into a collection?

How to do a blocking put on a channel ?

Tue, 08 Dec 2020 19:43:21 +0000

I am getting the following error

No more than 1024 pending takes are allowed on a single channel

However, I though that if i defined a channel with a specifed size , the puts would block.

(def event-chan (chan 10))

I am calling this in a loop

(>!! event-chan evt)

My expectation is that it would block is there were pending 10 items in the channel .. however does not seem to be happening. My code is reading a fifo queue in a database and proceesiing it. it seems to not block even if the items are pending in the channel

edit: updated to copy paste the full actual code.

(defn process-edn [{:keys [data code]}]
; lots db processing code here
)
  
(def event-chan (chan 10))
  
(defn eat-now-or-later[evt]
    (if ( = (evt :code) :loadevt)
        (do (println "sync processing load event ")
            (process-edn evt))
        (>!! event-chan evt)
      ))
  
  (defn async-deque [shutdown?]
    (time! dq-call-processing-time
           (let [k-t (ftup/from commons/*JOB_FIFO_EVENT_QUEUE*)
                 fdb (cfdb/select-api-version cfdb/clj-fdb-api-version)]
             (go (while true (process-edn (<! event-chan))))

             (loop[evt (with-open [^Database db (cfdb/open fdb)] (fifo/dequeue db k-t))]
              
              (if (or (shutdown?)  (nil? evt)) 0
                  
                  (do                   
                   (eat-now-or-later evt)  
                   (recur (with-open [^Database db (cfdb/open fdb)] (fifo/dequeue db k-t))))
                  )
              )))
    (ptasks/print-stats))

The above is the function definition. I am calling this function from the daemon code below

(ns dqdaemon.core
  (:require [shutdown.core :as shutdown])
  (:require [com.videocloudmanager.petikaa.dequeue-tasks :as dqt])
 )

;; A crude approximation of your application's state.
(def state (atom {}))

(defn shutdown?[] (false? (:running @state)))

(defn init [args]
  (swap! state assoc :running true)
  (shutdown/add-hook! ::descriptive-name #(do
                                            (swap! state assoc :running false)         
                                            (println "It's about to go down!")))
  )

(defn start []
  (while (:running @state)
    (println "tick")
     (dqt/async-deque shutdown?)
    (Thread/sleep 2000)))


;; Enable command-line invocation
(defn -main [& args]
  (init args)
  (start))

Update:
I understand that this is not an issue with blocking puts. It is because my code is creating unlimited goloops.

This code is being called in a loop and the parent method of this loop , async-dequ, is being called in a forever loop.

(go (while true (process-edn (<! event-chan)))))

I am moving this code out of the loop-recur and into the main method to initialize when the daemon is started

documentation issues on clojurescript promises interop

Wed, 16 Sep 2020 20:35:21 +0000

https://clojurescript.org/guides/promise-interop

this is given as the way to setup core.async for <p! :

(:require
   [cljs.core.async :refer [go]]
   [cljs.core.async.interop :refer-macros [<p!]])

We are using current shadow-cljs and node target, and we find that this recipe leaves 'go' exposed as a function, not a macro.

replacing with :refer-macros [go] fixes the issue

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

Mon, 07 Sep 2020 12:47:54 +0000

ClojureScript 1.10.520, could not reproduce in Clojure. Reproduced in core.async 1.3.610 and 1.1.582, not reproducible in 1.0.567.

Looks the same as https://clojure.atlassian.net/browse/ASYNC-198?focusedCommentId=12026.

Code:

(ns app.main
  (:require [clojure.core.async :as a]))

(a/go
  (try
    (prn :ret
         (try
           (throw (ex-info "expected" {}))

           (catch js/Error e
             (prn :catch1)
             (throw e))

           (finally
             (prn :finally))))

    (catch js/Error _e
      (prn :catch2))))

Expected:

:catch1
:finally
:catch2

Actual:

:catch1
:finally
:ret #error {:message "expected", :data {}}

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

Mon, 20 Apr 2020 22:53:25 +0000

I find it limiting that ex-handler for async/pipeline(-blocking) accepts an exception only, but not the value for which that exception occurred. Another arity (fn [ex v]) would be useful for use cases such as retrying, better error reporting etc. I guess it could be supported in a backward-compatible way via reflection arity checking (e.g. https://stackoverflow.com/a/1813967).

Add support for
Sat, 29 Feb 2020 20:24:26 +0000

Is there a good reason why `<!!` isn't supported in cljs? If there isn't, wouldn't it be great to add support for `<!!`?

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

Mon, 13 Jan 2020 08:24:38 +0000

We encountered a thorny problem with core.async:

In some situations "No more than 1024 pending takes are allowed" is raised in an async-dispatch thread, even though there are actually only 1024 pending takes.
That situation can be triggered quickly with the following code:

`
(dotimes [_ 5000]
;; - 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)))

Environment:
Mac OS, JDK 8, Clojure 1.10.0, core-async 0.6.532

core.async pipeline arguments order

Thu, 26 Dec 2019 12:47:08 +0000

I'm curious about why in the 3 pipeline* functions in core.async, the to argument is expected before the from argument. Looks like originally, with the pipe function, the order was the opposite, but when the pipeline functions where added, there was a reason to swap the order.

There is also a todo on the code to change arguments order for pipe:
https://github.com/clojure/core.async/blob/39488d33b4933ef3eb4c4aac485ad21ac3c78825/src/main/clojure/clojure/core/async.clj#L574

A literal meta in cljs.core.async

Tue, 24 Dec 2019 20:02:54 +0000

Is it a bug or a technical impossibility to implement a literal meta in cljs version of core.async?

(ns clojurescript-example
  (:require
   [cljs.core.async :as a]))

(let [x (a/go ^:foo [:x])]
  (a/go
    (prn (meta (a/<! x))))) ;; nil

(ns clojure-example
  (:require
   [clojure.core.async :as a]))

(let [x (a/go ^:foo [:x])]
  (a/go
    (prn (meta (a/<! x))))) ;; {:foo true}

where is the blocking operation?

Thu, 31 Oct 2019 22:54:34 +0000

This change https://github.com/clojure/core.async/commit/3429e3e1f1d49403bf9608b36dbd6715ffe4dd4f changes the number of threads created by a pipeline pretty significantly(0 new threads vs N new threads) and removes the only difference between pipeline and pipeline-blocking while maintaining the separate existence , which seems odd, so I am trying to understand the purpose of it.

I have seen Alex say he found a bug with a blocking operation in pipeline and fixed it by making pipeline and pipeline-blocking act the same, so I think that refers to this commit.
What I don't understand is where the blocking operation is in the old version. The only thing I see that might be it is the use of >!! in the process function, but it is called once on a channel with a buffer of size 1, that is created immediately before and closed right after, so there is no way other operations can be pending on it, so it might as well be a put! which never blocks.

if #1 really is the reason behind the commit, I don't understand it in light of #2, if #1 is not the reason behind the commit does anyone know what it is?

Is #2 straight up wrong? Is there some way that the >!! can block given a non-shared channel with space in its buffer?

Is this about blocking xforms? I thought that was caveat emptor.

Will pipeline be marked as deprecated since it now has the same behavior as pipeline-blocking?

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

Tue, 17 Sep 2019 09:04:58 +0000

It seems to me that alt!! does complete put operations only when the channel is already closed from the beginning, but not when the channel is closed while alt!! is waiting. That is unlike read operations, which complete with a nil value.

Is that an intended behaviour? If so, that is quite 'unfavourable' for obvious reasons. It should at least be marked with a big warning sign in the docs then.

Any plans for core.async with Project Loom?

Fri, 26 Jul 2019 07:32:12 +0000

I was wondering if there are any plans to revamp/rewrite core.async now that Project Loom seems well underway.... https://www.reddit.com/r/Clojure/comments/ch90sh/fibers_and_continuations_in_clojure_with_project/

Cljs timeout timers skiplist is naive linked list

Mon, 17 Jun 2019 13:10:52 +0000

The skip list for the cljs timers has a bug which is readily apparent: a loop without a recur:

{code:java}
(let [x (skip-list-node k v (make-array new-level))]
  (loop [i 0]
    (when (<= i level)
      (let [links (.-forward (aget update i))]
        (aset (.-forward x) i (aget links i))
        (aset links i x)))))

This is from the `put` function. This ordinarily would be a terrible bug except that the link at 0 is just the naive linked-list link and it omits the "skips" of the skip list. A trivial patch fixes this to recur from the when form.

This has an implication to the ceilingEntry function however:

{code:java}
  (ceilingEntry [coll k]
    (loop [x header level level]
      (if-not (neg? level)
        (let [nx (loop [x x]
                   (let [x' (when (< level (alength (.-forward x)))
                              (aget (.-forward x) level))]
                     (when-not (nil? x')
                       (if (>= (.-key x') k)
                         x'
                         (recur x')))))]
          (if-not (nil? nx)
            (recur nx (dec level))
            (recur x (dec level))))
        (when-not (identical? x header)
          x))))

This function allows to "overshoot" the key you are searching for, presumably finding the "next" node. With a simple linked list this is fine and well-defined. However, with a skip list, this allows for drastic and non-deterministic overshooting depending on how big a skip is.

This needs to be patched to only overshoot when in the lowest linked list and not in any of the skip list links.

(CLJS) cljs alts! not non-deterministic

Tue, 11 Jun 2019 04:28:02 +0000

In cljs, {{clojure.core.async/random-array}}'s shuffle was incorrect, leading it to always return \[1 0\] for arg n=2. This breaks the promise that alts! is non-deterministic w.r.t. op selection by always trying the second element first. Additionally, the first op is never chosen first for alts! of any size N>1.

Use goog.array.shuffle to do the shuffle instead. (This API is also used by cljs.core/shuffle)

New implementation passes tests and behaves better:

{code:java}

cljs.user=> (frequencies (take 10000 (map vec (repeatedly #(a/random-array 2)))))
WARNING: var: cljs.core.async/random-array is not public at line 1 <cljs repl>
{[0 1] 4964, [1 0] 5036}

cljs.user=> (frequencies (take 10000 (map vec (repeatedly #(clojure.core.async/random-array 3)))))
WARNING: var: cljs.core.async/random-array is not public at line 1 <cljs repl>
{[0 1 2] 1720, [1 2 0] 1679, [2 0 1] 1669, [0 2 1] 1573, [1 0 2] 1682, [2 1 0] 1677}
cljs.user=> (pp)
{[0 1 2] 1720,
[1 2 0] 1679,
[2 0 1] 1669,
[0 2 1] 1573,
[1 0 2] 1682,
[2 1 0] 1677}
nil

Add a closable-timeout function that always return a fresh channel

Mon, 03 Dec 2018 17:22:10 +0000

Hello,

This is my first patch in a core Clojure project. I will try to be as clear and verbose in the problem statement,
the solution the patch brings and the value proposition.

h3. Problem:

The {{timeout}} function returns a channel that maybe unsafe to call {{close!}} on. It's because in an application that creates
several timeout channels very closely in time, the newly created timeout channels will in fact be the previously created channels
if the call to `timeout` happens less than {{clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS}} after the previous ones (currently 10 ms).

It means that manually closing a channel causes code that creates new ones shortly after will in fact retrieves a closed channel.
Taking from it, using {{alt!}} etc hence exhibits unwanted behavior.

It happened to us when we tried to create a safer take in the context of a high traffic website (10+ millions page views/day), which uses timeout channels
against normal channels for calling external services and ensures that no go block is indefinitely waiting for a channel to clause.

Here's the code, to give more context to the discussion:

(defmacro <?
  "Safer <! (take), that times out to avoid waiting infinitely"
  [port]
  `(let [timeout-ch# (async/timeout 120000) ;; 2 minutes
         val# (as/alt!
                timeout-ch# :timeout
                ~port ([v#] v#))]
     (cond
       (instance? Throwable val#) (throw val#)
       (= val# :timeout) (throw (ex-info "A timeout occur in a channel async" {}))
       :else val#)))

Using timeout channels (with long timeouts of 2 minutes) without closing them solved our core problem (too many TCP sockets in CLOSE_WAIT state)
but immediately caused the application to use approximately 10%+ CPU and way more memory than before.

After analyzing the problem, we concluded that leaving the timeout channels as is resulted in them continuously executing the code
that checks if their time had passed, even if the "safe take" go block had returned. And most of the time, it's not the external
services that time out or fail, they just work and respond fast.

So for us, closing (with {{close!}}) the timeout channels immediately after the {{alt!}} failed because of the {{TIMEOUT_RESOLUTION_MS}} sharing.
After the first {{<?}}, subsequent calls to {{<?}} that happens shortly after would fails since previous timeout channels were reused and already closed.
In the context of a web application it's very common to do several requests to external services (and coordinates them with core.async)
before being able to send the response. I believe many other kind of applications would behave the same way.

h3. Solution:

Our solution consists in creating another timeout function that:
- doesn't try to reuse channels created in the {{TIMEOUT_RESOLUTION_MS}} window
- always returns a fresh channel
- doesn't add the newly created channel to the {{^ConcurrentSkipListMap timeouts-map}} to avoid collaboration with other normal timeout channels.

Current name is {{closable-timeout}}, to be validated. It could be {{safe-timeout}} or something else.

Please note that we already implemented and deployed the solution to production. We measured precisely the impact and are
confident that this is potentially a good patch that the wider Clojure community would benefit from. What we measured:

- When using the normal timeout channels (without closing them manually), memory usage (committed heap) reached our maximum level very quickly (9GB)
on all our 4 machines and stabilized at this level. Our understand is that it's because each of our requests would create
on average 4 timeout channels that would be garbage collected at least 2 minutes after.
During this 2 minutes window we would get lots of requests, so lot of garbage would be be created before being collected.
The garbage collector (G1) would use on average 3-4% CPU time working (young generation).

- When using our custom timeout channels, memory usage (committed heap) immediately returned to normal (2-5GB) depending on the machine
and stabilized at this level. We believe that it's because garbage channels are collected much faster so they don't pollute the heap
and create much less data to collect for the GC. CPU time spent in collection decreased back to our normal levels of operation (less than 0.5%).
Our understanding of G1 is that one of its specialty is doing much more frequent garbage collections of small amount of data,
and doing so in a much more efficient way than previous GC. Being able to close timeout channels manually allowed our application
to align with G1 behaviour closely.

The patch includes a test that demonstrates the problem, as well as another test that just use instead the new {{closable-timeout}} channel
that doesn't exhibit the problem.

h3. Value proposition:

Why submitting a patch while it can be done in user-space? Because to implement this functionality we had to rely on the
{{clojure.core.async.impl.timers}} namespace which should be an implementation detail, and also had to add the channel
to the {{^DelayQueue timeouts-queue}} from the same namespace by using the {{@#'}} trick (like this {{(def ^DelayQueue async-timeouts-queue @#'clojure.core.async.impl.timers/timeouts-queue)}}).
Hence any refactoring of core.async could break our code or anyone doing the same thing.

h3. Things to consider:

- We haven't tested with other garbage collectors, nor on the GraalVM.
- We didn't change at all the current timeout implementation, understand that this {{TIMEOUT_RESOLUTION_MS}} trick is a performance optimization.
- We added a note in the docstring of the normal timeout about the fact that normal timeout channels are unsafe to close manually.
- We wonder if it would be better, for normal timeout channels to throw an Exception when calling {{close!}} on them since it's unsafe.
- I haven't given lots of thoughts about CLJS core.async, since this repo contains only Clojure code but both CLJ and CLJS tests (no idea how the thing works...)

PS: I have no idea if I should have run some script from the {{script}} folder.
PS2: Not sure if this is an enhancement or a defect, but as it bit us hard I chose defect.
PS3: I'm open to all comments, no string attached.

let in go block leaks memory

Tue, 13 Nov 2018 10:25:49 +0000

When a let binding gets used across a blocking operation, the binding leaks out of the let.

`
(async/go-loop []

(let [msg (async/<! in-ch)]
  (if msg
    (let [stuff (vec (range 1 100000))]
      (async/<! out-ch stuff)
      (println stuff)
      (recur))
    (recur))))

The {{stuff}} binding gets stuck into the the state-machine state. This persists across the {{recur}}, until the binding is next encountered.

(In our case, a few GBs had accumuled by that time.)

Ideally, the fields in the state that represent local variables would be nulled when the variables go out of scope.

can't assign instance fields in go blocks

Tue, 06 Nov 2018 11:08:40 +0000

IOC doesn't properly handle set!. The following snippet fails to compile because set! is treated like a function call, evaluating field access first instead of treating the whole form as a field instance assignment.

(a/go (set! (.-gridx (java.awt.GridBagConstraints.)) (a/<! (a/go 0))))

go ignores async code in letfn body

Tue, 16 Oct 2018 13:38:59 +0000

The following snippet fails because <! is outside of {{go}} boundaries.

`
(let [port (a/chan)]
(a/go

(letfn [(my-even? [n] (if (zero? n) true (my-odd? (dec n))))
        (my-odd? [n] (if (zero? n) false (my-even? (dec n))))]
  (my-even? (a/<! port)))))

Async code in {{letfn}} body should be rewritten by the {{go}} macro, given all bound functions can be properly initialized when the body starts.

an exception caught in a finally block swallows the exception of the outer try

Sun, 23 Sep 2018 16:59:21 +0000

The inner try exception handling clears the exception status of the outer try, making it return successfully instead of rethrowing.
In the following snippet, prn is executed althought it should be dead code.

(let [chan (a/chan)
      npe! nil]
  (a/go
    (try (npe!)
         (finally
           (try (a/>! chan (npe!))
                (catch NullPointerException _))))
    (prn "this is fine.")))

some locals are not cleared in go blocks

Thu, 30 Aug 2018 13:17:42 +0000

Running this code eventually throws OOME :

`
(let [c (a/chan)]
(a/go (while (a/<! c)))
(a/go

(when-some [xs (range)]
  (doseq [x xs]
    (a/>! c x)))))

This one (with {{let}} instead of {{when-some}}) works fine :

`
(let [c (a/chan)]
(a/go (while (a/<! c)))
(a/go

(let [xs (range)]
  (doseq [x xs]
    (a/>! c x)))))

In the former, the range seq is stored on the heap (in go block's state array) and retained for the whole doseq iteration, althought it's not needed anymore after loop initialization.
In the latter, the range seq is stored on the stack so the compiler is able to perform its local clearing magic.

This behavior is likely to happen for every value spanning across multiple ssa blocks.

pipeline does not stop consuming from when to is closed

Thu, 17 May 2018 17:26:02 +0000

The docs for pipeline say "Will stop consuming the from channel if the to channel closes." however currently the go block that is reading results and putting to the to channel does a >!, and checks the return value to stop trying to output the current output value, but then goes ahead and tries to process the next output anyways. Thus, if the to channel is closed, the pipeline will continue reading, processing, and attempting to spit values at the to channel without stop.

Also, even if it did stop, some number of values will already have been read from the from channel (1 may be in-process in the output go block, N may be in the results channel, and N may be parked in flight in process go blocks).

(require '[clojure.core.async :as a])
(let [from (a/to-chan (range 100))
      to (a/chan 1)]
  (a/pipeline 1 to (map #(doto % println)) from)
  (a/close! to))
;; prints 0...99
;; Expect: should print no more than 4 items (1 in to, 1 in out go, 1 in results chan, 1 in process go)

*Proposed:* One option would be to change the doc string and not promise this behavior. Another would be to cause the close to flow back through the pipeline structure, shutting it all down.

(CLJS) Cannot use (js-debugger) in go block

Mon, 16 Apr 2018 15:57:10 +0000

To see the error, run the following:

clojure -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}org.clojure/core.async {:mvn/version "0.4.474"}}}' -m cljs.main -e "(require '[cljs.core.async :refer [chan go]]) (go (js/console.log \"Foo\") (js-debugger) (js/console.log \"Bar\"))"

which will generate a Js error like "SyntaxError: expected expression, got keyword 'debugger'"

The compiled Js output will contain something like:

{code:javascript}var inst_2199 = debugger;

but {{debugger}} is a statement, not an expression that can be assigned.

`go` fails to compile expressions with literal `nil` as a let value

Mon, 15 Jan 2018 14:41:35 +0000

Minimal repro:

clojure.core.async=> (fn [] (go
                              (let [a nil
                                    foo (identity a)]
                                (<! foo))))
CompilerException java.lang.RuntimeException: Unable to resolve symbol: a in this context, compiling:(NO_SOURCE_PATH:1207:41)

*Patch*: 0001-ASYNC-212-fix-expressions-with-nil-local.patch

`a/map` close out channel immediately when any one of inputs closed

Tue, 09 Jan 2018 07:24:13 +0000

(def c1 (chan)) (def c2 (chan)) (def out (a/map vector [c1 c2])) (a/close! c1) (a/<!! out) ;; will hangs until I put item to `c2` or close `c2`

I think the better way is close output channel immediately when any of input channels closed.

Puts committed on take! when buffer is full and buffer contains an expanding transducer

Sat, 06 Jan 2018 17:21:34 +0000

This issue came up here: https://groups.google.com/d/topic/clojure/w_p4f3gNo3s/discussion
Another (possibly) related previous discussion: https://groups.google.com/d/topic/clojure-dev/9Ai-ZuCezOY/discussion

The scenario:
1. a channel has a fixed buffer of 1 and an expanding transducer (mapcat identity)
2. a single put! is performed with a collection (C1)
3. a blocking take! is initiated in another thread
4. a second put! is performed with another collection

I expected any put!'s to fail until all elements of collection C1 are taken from the channel.

Non-blocking put!'s (via offer!) do fail until then.

Blocking put!'s do block -- but only until a single take! is executed on the channel. That's surprising. Where does the put!'s value go? Everything does continue to "work" as expected, but the buffer acts like it has grown to size 2 (2 input collections, 1 partially output via the transducer)

I believe this is resolved by checking whether the buffer is full during a take! after the call to (impl/remove! buffer) but before processing any puts. See the patch for exactly what I mean. I'm not sure whether this change breaks anything as I'm not too familiar with this codebase; though tests do pass.

! should be macros

Wed, 13 Dec 2017 19:39:33 +0000

From a user perspective, <! and >! are not functions, since they can't be used as functions inside a go block; e.g. (go (apply <! ...)) is not a valid form. This is a problem, since it 1) causes confusion among users, and 2) causes bugs in other macros, e.g. CLJ-2291.

Proposed solution: make <! and >! macros.

Backwards compatibility: the change shoudn't introduce any breaking changes, since <! cannot be used as a function anyway. The change will introduce a mismatch between <!! and <!, one being a function and the other not, but that mismatch is in line with the differences in the semantics between the two.

Potentially, it would also move ">! used not in (go ...) block"-type errors to compile-time, cleanly solving some issues reported earlier, e.g.: (link: https://dev.clojure.org/jira/browse/ASYNC-168?focusedCommentId=42881&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-42881 text: ASYNC-168)

alts!! completes more than one operation when reading and writing to the same channel.

Wed, 15 Nov 2017 16:45:34 +0000

The (link: https://github.com/clojure/core.async/blob/2afc2dc5102f60713135ffca6fab993fb35809f0/src/main/clojure/clojure/core/async.clj#L277 text: documentation) states:

"Completes at most one of several channel operations"

When running the following example, the expected outcome would be a deadlock, but the code returns either (link: 42 c) or (link: true c).

(let [c (clojure.core.async/chan)] (clojure.core.async/alts!! [c [c 42]]))

Loop in go breaks type hints

Mon, 13 Nov 2017 00:57:38 +0000

Type hinting inside of go-loop or a go block with a loop in it loses the type hinting information. It appears that a channel must be read from in order for the data to be lost.

`
user=> (require ['clojure.core.async :as 'async])
nil
user=> (import 'java.util.Date)
java.util.Date
user=> (set! warn-on-reflection true)
true
user=> (let [a [(Date.) (Date.)] #_=> ch (async/chan)]
#=> (async/go-loop []
#=> (when (async/<! ch)
#=> (println (.getDate ^Date (get a 0)))
#=> (recur))))
Reflection warning, /tmp/form-init7283017118477479525.clj:3:3 - reference to field getDate on java.lang.Object can't be resolved.

object[clojure.core.async.impl.channels.ManyToManyChannel 0x2572eb4e "clojure.core.async.impl.channels.ManyToManyChannel@2572eb4e"]

user=> (let [a [(Date.) (Date.)] #_=> ch (async/chan)]
#=> (async/go-loop []
#=> (when (async/<! ch)
#_=> (println (.getDate ^Date (get a 0))))))

object[clojure.core.async.impl.channels.ManyToManyChannel 0x12e8b6a3 "clojure.core.async.impl.channels.ManyToManyChannel@12e8b6a3"]

user=> (let [a [(Date.) (Date.)]]
#=> (async/go-loop []
#=> (println (.getDate ^Date (get a 0)))
#=> (throw (Exception. "repl abort"))
#=> (recur)))
12

object[clojure.core.async.impl.channels.ManyToManyChannel 0x1b48111e "clojure.core.async.impl.channels.ManyToManyChannel@1b48111e"]

Exception in thread "async-dispatch-1" java.lang.Error: java.lang.Exception: repl abort

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1155)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Caused by: java.lang.Exception: repl abort

at user$eval1611$fn__1618$state_machine__6321__auto____1621$fn__1623$fn__1625.invoke(form-init7283017118477479525.clj:3)
at user$eval1611$fn__1618$state_machine__6321__auto____1621$fn__1623.invoke(form-init7283017118477479525.clj:2)
at user$eval1611$fn__1618$state_machine__6321__auto____1621.invoke(form-init7283017118477479525.clj:2)
at clojure.core.async.impl.ioc_macros$run_state_machine.invokeStatic(ioc_macros.clj:973)
at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invokeStatic(ioc_macros.clj:975)
at user$eval1611$fn__1618.invoke(form-init7283017118477479525.clj:2)
at clojure.lang.AFn.run(AFn.java:22)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
... 2 more

Pausing in mix is note effective

Fri, 22 Sep 2017 21:24:50 +0000

The following happens when using {{mix}}:

(def c1 (to-chan (range 100 105))) (def c2 (to-chan (range 10 15))) (def mch (chan)) (def m (mix mch)) (admix m c1) (admix m c2) (toggle m {c1 {:pause true}}) => true (<!! mch) => 100 (<!! mch) => 101 (<!! mch) => 10

Writing on a closed channel doesn't commit the handler

Thu, 21 Sep 2017 14:12:16 +0000

(let [closed (doto (a/chan) a/close!)
      open (a/chan)]
  (a/go-loop []
    (a/alts! [open [closed true]] :priority true)
    (recur)))

throws

Exception in thread "async-dispatch-1" java.lang.AssertionError: Assert failed: No more than 1024 pending takes are allowed on a single channel.
(< (.size takes) impl/MAX-QUEUE-SIZE)
at clojure.core.async.impl.channels.ManyToManyChannel.take_BANG_(channels.clj:235)
at clojure.core.async$do_alts$fn__8030.invoke(async.clj:253)
at clojure.core.async$do_alts.invokeStatic(async.clj:245)
at clojure.core.async$do_alts.invoke(async.clj:237)

my analysis is that when a write is attempted on a closed channel the handler should be commited, so as to allow cleanup of the handler registrations on other channels.

See https://github.com/clojure/core.async/blob/822920a45e5ea7fa28641922559fdeb888c15d05/src/main/clojure/clojure/core/async/impl/channels.clj#L74-L75

"dynamic binding + parking" removes top values of dynamic bindings outside

Mon, 11 Sep 2017 13:57:16 +0000

Parking inside binding block removes current values of dynamically bound vars.

Example:

`
(require '[clojure.core.async :as async :refer [go <!]])</p>

(def ^:dynamic d)

(go
(binding [d :bound]

(println d)
(<! (async/timeout 10))
(println d)))

Here is the output:

:bound

object[clojure.lang.Var$Unbound 0x15f8a952 Unbound: #'user/d]

Channel returned by to-chan not immediately ready for taking?

Fri, 11 Aug 2017 17:43:32 +0000

Not sure if this is really a bug but it stroke me as odd:

(async/poll! (async/to-chan [1 2 3])) ; => nil

Seems like the channel returned by {{to-chan}} should always be immediately ready for taking. Then again this is not mentioned in its docstring so maybe it's all fine. Just thought I'd file it in case it might hint at some deeper issue with poll! or {{to-chan}}.

(CLJS) A "finally" in a "try" in a "go" block is skipped in f a string is thrown.

Thu, 13 Jul 2017 11:06:19 +0000

In ClojureScript a "finally" is ignored if a string is thrown and the enclosing "try" is in a "go" block.

Example code:

(ns demo
(:require-macros
(link: cljs.core.async.macros :refer [go)]))

;; Prints: "in a finally"
(go (try (throw (ex-info "THROWN" nil)) (finally (println "in a finally"))))

;; Prints: "in a finally"
(go (try (throw (js/Exception. "THROWN")) (finally (println "in a finally"))))

;; Prints: "in a finally"
(go (try (throw (#js {})) (finally (println "in a finally"))))

;; Prints: "in a finally"
(try (throw "THROWN") (finally (println "in a finally")))

;; Prints: nothing
(go (try (throw "THROWN") (finally (println "in a finally"))))

(CLJS) A "finally" including an "if" breaks the result of the enclosing "try" if the "try" is in a "go" block

Thu, 13 Jul 2017 10:59:31 +0000

If there is a "if" in a "finally" block and the enclosing "try" is in a CLJS "go" block, then the result of the "try" is always nil.

Example code:

(ns demo
(:require-macros
(link: cljs.core.async.macros :refer [go)]))

;; Prints: "in a try"
(println (try "in a try" (finally (if true nil ))))

;; Prints: "in a try"
(go (println (try "in a try" (finally nil))))

;; Prints: nil
(go (println (try "in a try" (finally (if true nil )))))

Clojure Q&A - Recent questions in core.async

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

flow monitoring tool serves resources from unqualified path

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

Choosing between core.async pipelines

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

Typos in Flow guide

Is core.async.flow available in ClojureScript?

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

core.async go block error with clojure 1.12 method values

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

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

Virtual thread executor for core.async

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

core.async readme oversight

core.async test hangs on single-cpu system

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

How to do a blocking put on a channel ?

documentation issues on clojurescript promises interop

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

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

Add support for Sat, 29 Feb 2020 20:24:26 +0000 Is there a good reason why <!! isn't supported in cljs? If there isn't, wouldn't it be great to add support for <!!?

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

core.async pipeline arguments order

A literal meta in cljs.core.async

where is the blocking operation?

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

Any plans for core.async with Project Loom?

Cljs timeout timers skiplist is naive linked list

(CLJS) cljs alts! not non-deterministic

Add a closable-timeout function that always return a fresh channel

let in go block leaks memory

can't assign instance fields in go blocks

go ignores async code in letfn body

an exception caught in a finally block swallows the exception of the outer try

some locals are not cleared in go blocks

pipeline does not stop consuming from when to is closed

(CLJS) Cannot use (js-debugger) in go block

`go` fails to compile expressions with literal `nil` as a let value

`a/map` close out channel immediately when any one of inputs closed

Puts committed on take! when buffer is full and buffer contains an expanding transducer

! should be macros

alts!! completes more than one operation when reading and writing to the same channel.

Loop in go breaks type hints

object[clojure.core.async.impl.channels.ManyToManyChannel 0x2572eb4e "clojure.core.async.impl.channels.ManyToManyChannel@2572eb4e"]

object[clojure.core.async.impl.channels.ManyToManyChannel 0x12e8b6a3 "clojure.core.async.impl.channels.ManyToManyChannel@12e8b6a3"]

object[clojure.core.async.impl.channels.ManyToManyChannel 0x1b48111e "clojure.core.async.impl.channels.ManyToManyChannel@1b48111e"]

Pausing in mix is note effective

Writing on a closed channel doesn't commit the handler

"dynamic binding + parking" removes top values of dynamic bindings outside

object[clojure.lang.Var$Unbound 0x15f8a952 Unbound: #'user/d]

Channel returned by to-chan not immediately ready for taking?

(CLJS) A "finally" in a "try" in a "go" block is skipped in f a string is thrown.

(CLJS) A "finally" including an "if" breaks the result of the enclosing "try" if the "try" is in a "go" block

Add support for
Sat, 29 Feb 2020 20:24:26 +0000

Is there a good reason why `<!!` isn't supported in cljs? If there isn't, wouldn't it be great to add support for `<!!`?