Clojure core.async Channels

core.async is a library. It doesn’t modify Clojure. It is designed to support Clojure 1.5+.

You can create a channel with the chan function. This will return a channel that supports multiple writers and readers. By default, the channel is unbuffered, but you can supply a number to indicate a buffer size, or supply a buffer object created via buffer, dropping-buffer or sliding-buffer.

The fundamental operations on channels are putting and taking values. Both of those operations potentially block, but the nature of the blocking depends on the nature of the thread of control in which the operation is performed. core.async supports two kinds of threads of control - ordinary threads and IOC (inversion of control) 'threads'. Ordinary threads can be created in any manner, but IOC threads are created via go blocks. Because JS does not have threads, only go blocks and IOC threads are supported in ClojureScript.

go is a macro that takes its body and examines it for any channel operations. It will turn the body into a state machine. Upon reaching any blocking operation, the state machine will be 'parked' and the actual thread of control will be released. This approach is similar to that used in C# async. When the blocking operation completes, the code will be resumed (on a thread-pool thread, or the sole thread in a JS VM). In this way the inversion of control that normally leaks into the program itself with event/callback systems is encapsulated by the mechanism, and you are left with straightforward sequential code. It will also provide the illusion of threads, and more important, separable sequential subsystems, to ClojureScript.

The primary channel operations within go blocks are >! (put) and <! (take). The go block itself immediately returns a channel, on which it will eventually put the value of the last expression of the body (if non-nil), and then close.

There are analogous operations for use on ordinary threads - >!! (put blocking) and <!! (take blocking), which will block the thread on which they are called, until complete. While you can use these operations on threads created with e.g. future, there is also a macro, thread, analogous to go, that will launch a first-class thread and similarly return a channel, and should be preferred over future for channel work.

You can put on a channel from either flavor of >!/>!! and similarly take with either of <!/<!! in any combination, i.e. the channel is oblivious to the nature of the threads which use it.

It is often desirable to be able to wait for any one (and only one) of a set of channel operations to complete. This powerful facility is made available through the alts! function (for use in go blocks), and the analogous alts!! (alts blocking). If more than one operation is available to complete, one can be chosen at random or by priority (i.e. in the order they are supplied). There are corresponding alt! and alt!! macros that combine the choice with conditional evaluation of expressions.

Timeouts are just channels that automatically close after a period of time. You can create one with the timeout function, then just include the timeout in an alt variant. A nice aspect of this is that timeouts can be shared between threads of control, e.g. in order to have a set of activities share a bound.

As with STM, the pervasive use of persistent data structures offers particular benefits for CSP-style channels. In particular, it is always safe and efficient to put a Clojure data structure on a channel, without fear of its subsequent use by either the producer or consumer.

core.async has obvious similarities to Go channels. Some differences with Go are:

Finally, Clojure is hosted, i.e. we are bringing these facilities to existing platforms, not needing a custom runtime. The flip-side is we don’t have the underpinnings we would with a custom runtime. Reaching existing platforms remains a core Clojure value proposition.

I remain unenthusiastic about actors. They still couple the producer with the consumer. Yes, one can emulate or implement certain kinds of queues with actors (and, notably, people often do), but since any actor mechanism already incorporates a queue, it seems evident that queues are more primitive. It should be noted that Clojure’s mechanisms for concurrent use of state remain viable, and channels are oriented towards the flow aspects of a system.

Note that, unlike other Clojure concurrency constructs, channels, like all communications, are subject to deadlocks, the simplest being waiting for a message that will never arrive, which must be dealt with manually via timeouts etc. CSP proper is amenable to certain kinds of automated correctness analysis. No work has been done on that front for core.async as yet.

Also note that async channels are not intended for fine-grained computational parallelism, though you might see examples in that vein.

I’d like to thank the team that helped bring core.async to life:

And once again, Tom Faulhaber for his work on autodoc.

While the library is still in an early state , we are ready for people to start trying it out and giving us feedback. The CLJS port is still work in progress. Please have a look at the examples, which we will expand over time.

It should be noted that the protocols behind the implementation should still be considered an implementation detail for the time being, until we finish our exploratory work around network channels, which might impact their design.

I hope that these async channels will help you build simpler and more robust programs.

Rich