Re: [boost] Is there any interest in a library for actor programming? [preliminary submission]

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.

HTH,
Julian