Many real-world problems can be reduced to handling queues of messages. The messages are often ordered; it's not enough to define a single handler for all messages, since one message can dictate how future messages are handled. These messages also often represent future side effects; once they are modified, filtered, and accumulated, they will generally be sent over the network, printed to the screen, or written to disk.
It's this last fact that points to a crucial difference between these message queues and Clojure sequences: adding a message to the queue is not always transactionally safe. However, this doesn't mean that messages can never be transactionally enqueued. If enqueuing the message doesn't directly result in a side effect, transactions are perfectly fine.
In other words, transactions can safely encompass the modification, filtering, and accumulation of messages, as long as there's a clear separation between that process and using the end result to create side effects. A good solution should maximize the extent to which this is possible, and minimize the potential for mistakes.
some possible approaches
- Leverages existing operators for composing and applying functions
- Easy to understand and reason about, hides away side effects entirely
- Assumes simple call and response model for communication
- Works best when messages are unordered; one message cannot effect the handling of another without the introduction of state
- Works best when response is immediate
- Leverages existing operators for sequences
- Widely understood abstraction
- Immutability doesn't make it safe: neither LinkedBlockingQueues or queues of promises are transactionally safe to enqueue into (if deliver is used in a transaction that retries, it will throw an exception the second time around)
- Must manually allocate one thread per consumer
- No concept of timeout, consumer threads can starve forever
- Somewhat leaky abstraction; (next seq) takes a predictable amount of time pretty much everywhere else, and holding onto the head of the seq is a non-obvious trap to avoid
- node.js does it, so can we
- Simplest asynchronous mechanism there is
- If no one's listening, the data disappears
- node.js imposes order on events by using a single thread, to do the same Clojure must either:
- Make events per-thread (a la Erlang actors), which doesn't play nicely with Clojure's existing concurrency primitives
- Impose an ordering using state, which is arguably something that should be abstracted away