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