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: Bjorn Reese (breese_at_[hidden])
Date: 2014-05-17 04:17:25

I have a couple of major concerns with the current submission, and I am
going to suggest some substantial changes. I hope that it does not
discourage you too much.

I am going to suggest that:

  1. The library is broken into more fundamental building-blocks (which
     is what both Boost and the C++ standard is all about.)
  2. A more flexible data flow architecture is adopted.
  3. More use of existing Boost libraries.

I recognize three more fundamental building-blocks in the current
submission: active objects, messaging middleware, and data flow. I am
not against a higher level actor API, but the fundamentals need to be
in place first.

Building-blocks
---------------

Boost.Actor implements a distributed mailbox-based actor model. While
this is a building-block to some users, it is not fundamental. It
conflates the actor with distribution.

I suggest that you start with a non-distributed actor model. This is
simply an active object with an incoming message queue. This can be
used its own right without distribution and mailboxes. Many applications
have classes with a working thread inside them, and active objects
should strive to replace these classes [1].

Active objects have two important variation points: scheduling and the
queue type. Regarding scheduling there is a C++ standards proposal that
should be considered [2]. There is a GSoC project about this [3]. For
the distributed case, boost::asio::io_service also has to be considered.

There is also work done on message queues. We already have some in
Boost.Lockfree, or the wait-free multi-producer queue in the
Boost.Atomic examples, as well as sync_queue in Boost.Thread.

Architecture
------------

Once we have got active objects, the question is how do we connect them?
The variation points here are routing and transmission.

The mailbox approach is too simple for many applications. Partly
because it is too limited in some regards (e.g. push-only) and too
flexible in other regards (e.g. you cannot have fine-grained
access control or restricted visibility.)

There are several flow-based approaches that should be considered:
Boost.Iostreams has all the required concepts in place. There was a
Boost.Dataflow GSoC project [4] some years ago. There is a C++ standards
proposal [5] about C++ pipelines. See also the ZeroMQ guide [6] for
various examples.

Boost.Actor implements its own network protocol, but you often need to
integrate with an existing protocol, such as MQTT [7] or DDS [8].

We can add distribution by having proxies. The proxies can hide the
details about routing (e.g. actors may change location due to load
balancing or migration,) and network protocol.

Library reuse
-------------

Although Boost.Actor reuses other Boost libraries, it has implemented
quite a lot that either exists in other Boost libraries, or that could
be moved to those.

You have already mentioned that you do not use MPL, Serialization, and
Asio, so I will not delve into these, other than saying that I believe
that having your own socket implementation instead of using Boost.Asio
is a show-stopper.

Apart from these three, there are other libraries that should be 
considered. Boost.Actor has:

   o Own continuations instead of Boost.Thread (future::then)
   o Own producer-consumer queue instead of Boost.Lockfree
   o Own logging framework instead of Boost.Log, although I would
     prefer not having logging in a library at all.
   o Own UUID instead of Boost.UUID
   o Own time duration instead of Boost.Chrono

Then there are code that could be refactored to other Boost libraries
so they can be used in other contexts. For example:

   o Stacktrace dumper
   o RIPEMD hash function
   o MAC address

[1] 
http://www.drdobbs.com/parallel/prefer-using-active-objects-instead-of-n/225700095
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3785.pdf
[3] http://cs.mcgill.ca/~iforbe/
[4] http://www.dancinghacker.com/code/dataflow/index.html
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html
[6] http://zguide.zeromq.org/page:all
[7] http://mqtt.org/
[8] http://portals.omg.org/dds/