Quasar/Pulsar 0.2.0 - Distributed Actors, Supervisors, Fiber-Blocking IO and core.async
Quasar is a lightweight-threads, CSP and actors library for the JVM. Its main component is true lightweight threads (called fibers in Quasar), Go-like channels, and Erlang-like actors. You can read more about it in the introductory blog post.
Pulsar is Quasar’s Clojure API, and provides natural syntax for asynchronous programming. Working with fibers, channels and actors is as easy (or easier) in Pulsar as it is in Erlang (or Go).
Here’s what’s new in the release:
- Pulsar has got a user manual (Quasar’s documentation is forthcoming).
- Actors can now be discovered an distributed across a cluster. Quasar/Pulsar use Galaxy for clustering. While clustering is rather rudimentary in this release, many basic capabilities are present (like actor discovery, remote message-passing, remote detection of dead actors and failed nodes, passing actor references in messages).
- Erlang/OTP-like behaviors: gen-server, gen-event.
- Erlang/OTP-style supervisors.
- A select operation similar to Go’s.
- An implementation of Clojure’s core.async on top of Pulsar.
- Fiber-blocking IO: you can now use NIO in fibers, but the operations don’t block the OS thread; they block the fiber. Behind the scenes Quasar transforms Java’s asynchronous IO to fiber-blocking IO, to yield high-scalability but preserve a simple programming model. You can check out the Java and a Clojure examples.
Quasar and Pulsar are young and evolving quickly. In the coming weeks we’ll release bug-fixes and further minor enhancements, and we’re planning to add hot code-swapping in the next version.
In the meantime, consider the power of lightweight threads. You have the scalability and performance of an asynchronous model while writing code as simple as a basic single-threaded, blocking process. That’s scalability without the callbacks. Imagine hundreds-of-thousands, or even millions, of operations, each waiting on some input from other operations and producing output for others, all programmed as familiar single-threaded sequential processes. Like, say, a web server processing http and web-socket requests:
All those little handlers waiting on a database (or passing callbacks), waiting for services (or writing callbacks)… You can probably guess by now what we’ll be releasing next. It will (probably) be called COMSAT, and we’re planning on it supporting Java, Ruby and Clojure applications at first, and other JVM languages later.
Join our mailing list
Sign up to receive news and updates.