Boost logo

Boost :

Subject: Re: [boost] Is there any interest in a library for actor programming? [preliminary submission]
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-05-20 13:05:25

Dominik Charousset wrote:

> Please let's take the discussion to a different level. With this preliminary
> submission, I wanted to get a feeling if there is interest in a Boost.Actor
> library and if it can get enough momentum to eventually find a review manager.
> I guess this is the question I should have asked in my original post: "Do you
> think Boost should provide a high-level programming paradigm such as the actor
> model

If by "a high-level programming paradigm such as the actor model" you
mean a lock-free concurrency library with high conceptual abstraction,
then yes. I think the programming community at large, and the C++
community in particular, is dying for a solution to (hard)
concurrency that is safe and simple to use, powerful, performant as
well as general.

> and if you do, do you think the proposed design is the right one?"

I think the actor model is good, because messaging is the most
elegant solution to concurrency that I know of. However, I believe
the actor model is not the *best* possible approach to message
passing. The model is rather intricate, with monitors, links,
handles, timeouts, priorities, groups, and so on. To me it seems a
bit like the OO of concurrency: well-designed and insightful, but
needlessly complicated compared to a more general and powerful
paradigm such as generic programming. (To stick with the metaphor:
the status quo with locks and mutexes would be the concurrent
equivalent of pure procedural programming).

I think the *right* design would be a concurrent equivalent of
generic programming, where the only fundamental building blocks
should be a well-designed statically typed SPSC queue, move
semantics, a low-level thread launching utility (such as
boost::thread) and a concise generic EDSL for the linking of nodes
with queues. All further abstractions can be built on top of those
ingredients (a bit like the STL is built on top of templates). It
should allow me to do something like this:

start(readfile(input) | runlengthenc | huffmanenc | writefile(output));

At some point I want to publish a proposal for a library that does
exactly this, but I need to find more time to work on it. The good
news is that all necessary ingredients appear to already exist with
C++11, Boost.Proto and Boost.Lockfree.

As for libcppa, my impression from the manual is that it might be a
good implementation of the actor model. I dislike the option to
throw out static typing but I realise that's a matter of taste. I'm
a bit skeptical about the necessity and usefulness of built-in
network transparency, but you might be able to convince me that it
needs to be there.

> I know that this is a large library. The more important it is in my opinion to
> talk about concepts, API, and possibly documentation. Maybe I'm naive, but
> separating parts of the library or tweaking implementation details should be
> the last step, should it not?

I think it depends, but in this case I think separating
sublibraries would be wise. In addition to actor programming,
libcppa appears to provide three other facilities: CoW tuples,
guards and pattern matching, and platform-independent RTTI. It
would seem reasonable (and modular) to me to treat each as an
independent sublibrary and review them as such.


Boost list run by bdawes at, gregod at, cpdaniel at, john at