chanl
2025-06-22
Communicating Sequential Process support for Common Lisp
Upstream URL
Author
Kat Marchan
Maintainer
Adlai Chandrasekhar
License
Not determined
What is ChanL?
--------------
"Wh-what you have to understand is that-that ChanL is not a big blob
of state. When you have a lot of global state with lots of threads,
you need to, you need to lock it down. It's like a truck, and if too
many people try to use that truck, you, you get problems. ChanL is
not a big truck. It's a series--it's a series of *tubes*."
- Sen. Ted Stevens
In a nutshell, you create various threads sequentially executing tasks
you need done, and use channel objects to communicate and synchronize
the state of these threads.
You can read more about what that means here:
- http://swtch.com/~rsc/thread/
- http://www.usingcsp.com/cspbook.pdf
Loading ChanL
-------------
ChanL uses asdf for compiling/loading, so in order to load it, you
must first make chanl.asd visible to your lisp, then simply
(asdf:load-system 'chanl)
The included examples can be loaded by doing
(asdf:load-system 'chanl.examples)
at the REPL after the main .asd has been loaded.
Compatibility
-------------
ChanL uses a subset of Bordeaux-threads for all its operations. All
other code is written in ANSI CL, so any lisp with a BT-compatible
thread library _should_ be able to use this library; however, due to
inconsistencies, ChanL is likely to fail on compilers that have not
been updated recently, so **please report portability problems!**.
ChanL is mainly developed on Clozure CL and SBCL, although it's been
casually tested on other lisps.
You can run the test suite to see how well it works on yours:
(asdf:test-system 'chanl)
Note that the test-suite depends on 5AM, which can be found at
http://github.com/sionescu/fiveam
Channel API
-----------
*[generic function]* `make-instance class &rest initargs &key &allow-other-keys`
*[method]* `make-instance (class channel) &rest initargs`
Returns a new channel object.
*[method]* `make-instance (class unbounded-channel) &rest initargs`
Returns a new buffered channel with a FIFO buffer with no maximum length.
*[method]* `make-instance (class bounded-channel) &key (size 1) &rest initargs`
Creates a new buffered channel object with a limited buffer
size. The buffer has a maximum size of SIZE. Bounded channel buffers
are FIFO. When the buffer is full, SEND will block until something
is RECVd from the channel.
SIZE must be positive and less than +maximum-buffer-size+, and
defaults to 1.
*[method]* `make-instance (class stack-channel) &rest initargs`
Returns a new buffered channel with a LIFO buffer with no maximum length.
*[constant]* `+maximum-buffer-size+`
This constant has an implementation-dependant value, fixed when
ChanL is loaded. It is the exclusive upper bound to the size of a
bounded-channel's buffer.
Note that this value might be further limited by memory constraints.
*[generic function]* `send channel value &key`
*[method]* `send (channel channel) value &key (blockp t)`
Tries to send VALUE into CHANNEL. If the channel is unbufferd or
buffered but full, this operation will block until RECV is called on
the channel. Returns the channel that the value was sent into. If
blockp is NIL, NIL is returned immediately instead of a channel if
attempting to send would block.
*[method]* `send (channels sequence) value &key (blockp t)`
SEND may be used on a sequence of channels. SEND will linearly attempt to send VALUE into one of
the channels in the sequence. It will return immediately as soon as it is able to send VALUE into
one channel. If BLOCKP is T (default), SEND will continue to block until one operation succeeds,
otherwise, it will return NIL when the sequence has been exhausted.
*[generic function]* `recv channel &key`
*[method]* `recv (channel channel) &key (blockp t)`
Tries to receive a value from CHANNEL. If the channel is unbuffered,
or buffered but empty, this operation will block until SEND is
called on the channel. Returns two values: 1. The value received
through the channel, and 2. The channel the value was sent into. If
BLOCKP is nil, this operation will not block, and will return
`(values NIL NIL)` if attempting it would block.
*[method]* `recv (channel sequence) &key (blockp t)`
RECV may be used on a sequence of channels. RECV will linearly
attempt to receive a value from one of the channels in teh
sequence. It will return immediately as soon as one channel has a
value available. As with the method for CHANNEL, this will return
the value received, as well as the channel the value was received
from. If BLOCKP is NIL, and operating on all channels in sequence
would block, `(values NIL NIL)` is returned instead of blocking.
*[macro]* `select &body clauses*`
Non-deterministically select a non-blocking clause to execute.
The syntax is:
select clause* -> result(s)
clause ::= (op form*)
op ::= (recv c &optional variable channel-var)
| (send c value &optional channel-var)
| else | otherwise | t
c ::= an evaluated form representing either one single channel,
or a sequence containing multiple ordered channels.
variable ::= a symbol, bound within form* to RECV's return value.
value ::= an form evaluated for the value to send to the channel.
channel-var ::= A symbol bound to the active SEND/RECV channel.
result(s) ::= the values returned by first clause to act up.
SELECT will first attempt to find a clause with a non-blocking op,
and execute it. Selecting a clause to execute is atomic, but
execution of the clause's body after the SEND/RECV clause executes
is NOT atomic. If all channel clauses would block, and no else
clause is provided, SELECT will thrash-idle (an undesirable state!)
until one of the clauses is available for execution.
SELECT's non-determinism is, in fact, very non-deterministic.
Clauses are chosen at random, not in the order they are written.
It's worth noting that SEND/RECV, when used on sequences, are still
linear in the way they go through the sequence -- the random
selection is reserved for individual SELECT clauses.
Please note that currently, the form for the channel in the RECV
and SEND clauses and for the value in the SEND clause might be
evaluated multiple times in an unspecified order. It is thus
undesirable to place forms with side-effects in these places. This
is a bug and will be fixed in a future version of ChanL.
Thread API
----------
*[special variable]* `*default-special-bindings*`
alist of bindings new threads should have; its template is:
'((*var1* 'value) (*var2* 'value2)).
*[function]* `pcall function &key initial-bindings name`
PCALL (mnemonic Parallel Call) calls FUNCTION in some thread.
FUNCTION must be a function of zero arguments. INITIAL-BINDINGS, if
provided, are bound around the execution, and should follow the same
template as *default-special-bindings*, also the defaults if no
keyword argument is given.
PCALL returns a task object representing this task. This object is
intended for interactive use in reflection and debugging, and
contains some of metadata about the execution. The NAME argument
can be used to initialize the name slot of the task object.
*[macro]* `pexec (&key (initial-bindings *default-special-bindings*)) &body body`
Executes BODY in parallel. INITIAL-BINDINGS, if provided, should be
an alist representing dynamic variable bindings that BODY is to be
executed with, as if with *default-special-bindings*. NAME can be
used to initialize the name slot of the returned task object. PEXEC
also returns a task.
Thread Introspection
--------------------
ChanL includes portable support for lisp threads through
bordeaux-threads, and adds some sugar on top, such as a built-in
thread pool. None of the thread functions here should be used in user
code, since they are meant exclusively for development purposes. Most
thread-related matters are automatically handled by the thread pool
already. In fact, not a single one of these should be expected to work
properly when you use them, so do so at your own risk.
*[class]* `task`
Tasks represent the bits of work carried out by threads. Task
objects should be treated as read- only debugging aids. The
functions TASK-NAME, TASK-THREAD, and TASK-STATUS return metadata
about the task. Since this is an experimental feature, its API is
likely to change -- the current behavior can be checked in
src/threads.lisp.
*[function]* `current-thread`
Returns the current thread
*[function]* `thread-alive-p thread`
T if THREAD is still alive
*[function]* `threadp maybe-thread`
T if maybe-thread is, in fact, a thread.
*[function]* `thread-name thread`
Returns the name of the thread.
*[function]* `kill thread`
Kills thread dead.
*[function]* `all-threads`
Returns a list of all threads currently running in the lisp image.
*[function]* `pooled-threads`
Returns a list of all threads currently managed by ChanL's thread pool.
*[function]* `pooled-tasks`
Returns a list of all tasks pending or live in ChanL's thread pool.
*[symbol-macro]* `%thread-pool-soft-limit`
This is a SETFable place. It may be used to inspect and change the
soft limit for how many threads the thread pool keeps around. Note
that the total number of threads will exceed this limit if threads
continue to be spawned while others are still running. This only
refers to the number of threads kept alive for later use. The
default value is 1000.
Writing your own channels
-------------------------
Currently, ChanL provides a very early API for writing your own channels easily.
*[class]* `abstract-channel`
This class is the ancestral superclass of all channels. CHANNELP
returns T for any instances of this class or its subclasses.
Direct subclasses of abstract-channel will have to define their own
SEND/RECV methods, which should meet the API requirements in order
to be compatible with ChanL.
*[class]* `channel`
This is the main unbuffered class used in ChanL. Unless you wish to
write a new synchronization algorithm for your custom channels, you
should subclass CHANNEL, since you then get to reuse ChanL's
build-in algorithm (which relies on locks and condition variables).
Subclasses of the CHANNEL class are able to extend behavior in a
fairly flexible way by simply writing methods for the following 4
generic functions:
*[generic function]* `send-blocks-p channel`
This function returns, as a generalized boolean, whether SEND
should block on this channel.
*[generic function]* `recv-blocks-p channel`
Like send-blocks-p, but for RECV.
Please note that the consequences of calling send-blocks-p and
recv-blocks-p in user code are *undefined* -- these functions are
called from specific points within the carefully instrumented
algorithms of the SEND and RECV methods specialized on the CHANNEL
class.
*[generic function]* `channel-insert-value channel value`
Methods on this function define what actions are taken to insert a
value into a channel. Methods should be specialized only on the
first argument. This function's return values are ignored.
*[generic function]* `channel-grab-value channel`
Methods on this function define how to retrieve a value from a
channel. This function must return at least one value, the object
retrieved from the channel, which will then be returned by RECV.
Additionally, ChanL uses and exports a number of abstract and
concrete classes to implement its buffered channels:
*[abstract class]* `buffered-channel`
Abstract class for channels using various buffering styles.
*[abstract class]* `queue-channel`
Abstract class for channels whose buffer works like a queue.
*[class]* `bounded-channel`
Class used by ChanL's bounded channels (queue channels that block
when the queue reaches a certain length).
*[class]* `unbounded-channel`
Class used by ChanL's unbounded channels, which are queues of
unlimited length (SEND never blocks)
*[class]* `stack-channel`
Class used by ChanL's stack channels. These channels' buffers are
unbounded LIFO stack structures.
Examples
--------
Create a channel:
(defvar *c* (make-instance 'channel))
Create a buffered channel with a buffer size of 5. Buffered channels
do not block on send until their buffer is full, or on recv until
their buffer is empty.
(defvar *c* (make-instance 'bounded-channel :size 5))
Read a value from a channel (blocks if channel is empty)
(recv *c*)
Write a value to a channel (blocks if channel is full, always blocks
on unbuffered channels)
(send *c* 99)
Wait for any of a number of things to occur:
(select
((recv c d)
(format t "got ~a from c~%" d))
((send e val)
(print "sent val on e~%"))
((recv *lots-of-channels* value channel)
(format t "Got ~A from ~C~%" value channel))
(otherwise
(print "would have blocked~%")))
Create a new thread continually reading values and printing them:
(pexec ()
(loop (format t "~a~%" (recv *c*))))
Create a new thread that runs a function:
(pcall #'my-function)
Please refer to the examples/ directory for examples of how ChanL
can be used, including a parallel prime sieve algorithm translated
from Newsqueak and an implementation of future-based concurrency.