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: Tim Keitt (tkeitt_at_[hidden])
Date: 2014-05-15 16:32:41

On Thu, May 8, 2014 at 12:30 PM, Dominik Charousset <
dominik.charousset_at_[hidden]> wrote:

> Hi all,
>
>
> attached you'll find the first preliminary submission for Boost.Actor as
> ZIP file along with the Manual in PDF version. You currently still need
> CMake, a Boost.Jam build file will follow. The project is hosted at GitHub:
> https://github.com/Neverlord/boost.actor
>
> To state the obvious: we [1] took our time, but not because we are not
> taking the boost submission serious. In fact, the opposite is true. We did
> refine libcppa (which is the base for Boost.Actor) over the last months
> based on community feedback - feedback from this mailing list, last year's
> C++Now, GitHub, and libcppa's mailing list. However, we are not just trying
> to lift our library into Boost. We want Boost.Actor to fit into Boost as
> good as possible - and we did significant changes to the API (see below),
> which also took time. Furthermore, we think performance is key when
> providing a native actor system. Boost.Actor/libcppa has now reached a
> level of performance with the latest version that lives up to our
> expectations - and hopefully to the expectations of (future) users as well.
> A brief performance evaluation [2] is attached. The graphs still mention
> 'libcppa' instead of Boost.Actor.
>
> I hope the lack of Boost.Jam support is not too much of an issue - I
> thought it would be a good idea to post the preliminary submission before
> the C++Now (you can meet me there!), to get people time to play with
> Boost.Actor beforehand.
>
>
> *Differences between Boost.Actor and libcppa*
>
> If you don't have any experience with libcppa, you can simply skip this.
> The most visible change is the removal of any_tuple and cow_tuple. The COW
> tuple implementation of libcppa is in our opinion not general enough and is
> too intermeshed with the type system. Instead, Boost.Actor provides the
> class `message` that is an opaque container from a user's point of view.
> Also, the pattern matching has been reduced to a minimal DSL for defining
> message handlers. The separate DSL for guard expressions is gone completely
> (a similar functionality still exists though). Since our pattern matching
> only worked with messages/any_tuples, we don't see too much use of it
> outside of Boost.Actor. We are still hoping for native pattern matching in
> C++ (N3449 proposed this a while ago) in which case our DSL would become
> unnecessary anyways. As a side-effect of removing all these parts,
> Boost.Actor has become a streamlined version of libcppa that is easier to
> grasp and that will be easier to maintain in the long run as well.
>
>
> *Boost.Actor depends on...*
>
> variant, optional, none, string_algorithms, intrusive_ptr, thread
> (currently as header-only dependency), context/coroutine (for cooperatively
> scheduled blocking actors). Some examples also require program_options.
>
>
> *Boost.Actor does NOT use...*
>
> (1) MPL. Boost.Actor uses a ludicrous amount of metaprogramming based on
> boost::actor::detail::type_list. I've tried to port it to MPL and wasted
> almost two days doing so. MPL is a great C++ library. Unfortunately, C++98,
> not C++11. Even after adding variadic helpers to reduce the amount of
> template instantiations, it would still explode and fail to compile. I've
> stopped after writing half the size of the current type_list utility
> functions and still wasn't able to reduce the amount of template
> instantiations significantly enough. That being said, I am looking forward
> to the GSoC project for MPL11.
>
> (2) Serialization. The first and most obvious problem I have with this
> library is the lack of a portable binary archive. String serialization is
> sufficient for a lot of applications, but the performance hit for both
> networking overhead and the string serialization itself is not acceptable
> in an actor system. Furthermore, simply adding such a binary archive would
> not be enough. The library does not give you a platform-independent
> representation of the type names, which is crucial. Also, one cannot create
> an instance of a type given only its type name and then deserialize its
> values from a network stream (I was thinking of ETI::key_register using the
> uniform names and ETI::find, but it only solves a part of the problem).
> Adding all of these capabilities on top of boost.serialization plus writing
> a portable binary archive (or maybe use something like EOS -
> http://epa.codeplex.com/) would probably result in more code and most
> likely in a more complicated design, i.e., would be harder to maintain.
> Maybe I miss the forest for the trees here and some experienced
> boost.serialization user knows a straightforward way I don't see. However,
> maybe there is interest in extending boost.serialization. I'd be happy to
> work on patches for adding uniform names, etc.
>
> (3) Boost.Asio. There is definitely potential to port the low-level parts
> of the middleman to Asio, I think. These changes would be transparent to
> the user, though, since users really only use the broker and can forget
> about the rest.
>
>
> *Separating parts of Boost.Actor?*
>
> Vicente J. Botet Escriba suggested to separate some parts of library.
> Namely the constexpr atom() [the other parts he suggested were removed,
> btw]. Aside from that, there are some C++11 utility functions that I think
> would be useful for other developers as well. Namely int_list [3] which can
> be used to create indices for variadic types such as tuples to allow users
> to apply the values of a tuple to a functor with apply_args [4]. type_list
> [5] is a powerful tool too, but I think this functionality goes to MPL11
> anyways. Something that might be worth lifting to the boost namespace is
> unit [6], which makes metaprogramming (for me) a lot easier by providing an
> easy way of lifting void to something useful and don't need to worry
> whether or not it might end up in a tuple or variant. MPL already has
> void_t, but it doesn't seem to be indented to be used the way I use unit.
> For binary serialization of floats, there is IEEE 754 packing/unpacking [6]
> that is based on http://beej.us/guide/bgnet/examples/pack2.c
>
>
>
> Sorry for the wall of text, the Mail got longer and longer somehow ...
>
>
>
> [1] "We" are a working group at the University of Applied Sciences
> Hamburg: http://inet.cpt.haw-hamburg.de/
>
> [2] The sources for all benchmark programs can be found here:
> https://github.com/Neverlord/cppa-benchmarks, please keep in mind that
> the evaluation uses libcppa, so the API used in the benchmarks is different.
>
> [3]
> https://github.com/Neverlord/boost.actor/blob/a0cab41e2946df7d751c59dfead0c2122da0fb77/boost/actor/detail/int_list.hpp
>
> [4]
> https://github.com/Neverlord/boost.actor/blob/ea53a515e09a98baa173ad379127c32ddf5e786e/boost/actor/detail/apply_args.hpp
>
> [5]
> https://github.com/Neverlord/boost.actor/blob/58d6177837788b2e54b8547531bda99fc7d795e0/boost/actor/detail/type_list.hpp
>
> [6]
> https://github.com/Neverlord/boost.actor/blob/644a47760d6b55eef438a81d7bcdc233d3575e2e/boost/actor/detail/ieee_754.hpp
>
> [7]
> https://github.com/Neverlord/boost.actor/blob/ea53a515e09a98baa173ad379127c32ddf5e786e/boost/actor/unit.hpp
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

I'm a bit of a lurker on this list but your post got me curious. The actor
model looks quite appealing. However a bit of self study led me to
http://www.theron-library.com/. Their code examples look more like
something I would use. I'd be curious to know how you see the differences.

Cheers,
THK

-- 
http://www.keittlab.org/