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

Subject: Re: [boost] Is there any interest in a library for actor programming?
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2013-05-20 20:02:42

> There was some discussion about this topic after the talk at the C++Now
> conference. I do agree that it is desirable to enable the compiler to
> verify the correctness of actor programs at compile time. However, in
> order to be able to ensure the correctness of a program, one would have to
> define not only all possible input messages, but the response types
> depending on the input as well. Consider this example:
> 
> actor_type<reacts_to<atom("add"),int,int>::with<int>,
>            reacts_to<atom("hello")>::with<std::string>> my_actor() {
>     return (
>         on(atom("add"), arg_match) >> [](int a, int b) {
>             return a+b;
>         },
>         on(atom("hello")) >> [] {
>             return "world";
>         }
>     );
> }
> 
> It's easy to check whether the interface is fulfilled. On each send, the
> compiler is able to check whether the given message matches actor_type and
> if the sender of the message (more precisely, the receiver of the response
> message) can handle the result. However, an approach like this cannot
> allow an actor to change its behavior. Hence, something as simple as the
> classical dining philosophers example
> (https://github.com/Neverlord/libcppa/blob/master/examples/message_passing
> /dining_philosophers.cpp) is not possible.
> 
> So, what if we allow actors to set a subset of given actor_type as
> behavior? Consider this example:
> 
> struct my_actor : actor_type<reacts_to<atom("init">,
>                              reacts_to<atom("add"),int,int>::with<int>,
>                              reacts_to<atom("hello")>::with<std::string>>
> {
>     void init() {
>         // check whether given match_expr defines a subset of defined
> actor_type
>         become (
>             on(atom("init")) >> [=] {
>                 become (
>                     on(atom("add"), arg_match) >> [=](int a, int b) {
>                         return a+b;
>                     },
>                     on(atom("hello")) >> [=] {
>                         return "world";
>                     }
>                 );
>             }
>         );
>     }
> }
> 
> This approach only allows class-based actors, because we need to evaluate
> the type information provided by 'this'. We would enable the compiler to
> check for *some* errors, but we could not verify, at compile time, that an
> actor actually implements its own interface, because we have no way the
> check whether an actor implements a message handler for each message it
> claims to be able to receive.
> 
> Even worse, both approaches do not allow actors to send/receive messages
> before replying to a request (unless message passing would be blocking,
> which would put an end to scalability). If we go back to the reply() API
> currently found in libcppa, we couldn't match request and response type.
> 
> 
> In any case, we would no longer be able to converts threads to actors on-
> the-fly:
> 
> int main() {
>     auto worker = spawn(...);
>     // Um... what is the type of 'self'? Is it a valid receiver for the
> response message?
>     send(worker, ...);
>     receive (
>         // again: what is 'self' allowed to receive/reply? ...
>     );
> }
> 
> 
> Long story short: a type-safe interface would be less powerful and would
> require more boilerplate code. However, perhaps there is a middle ground
> for doing type checks at runtime when compiled in debug mode?
> 
> int my_actor() {
>     // macro, defined as nothing if not compiled in debug mode
>     assert_protocol(reacts_to<atom("add"),int,int>::with<int>,
>                     reacts_to<atom("hello")>::with<std::string>);
> }
> 
> Perhaps it would be possible to include the first presented approach for
> type-safe actors along with the (dynamic) default actor API. In this way,
> we could compose type-safe subsystems of actors whenever a problem can be
> solved using the limited API.

Even if I have to admit that I don't understand all implication of what
you're saying, I would like to assert that it is possible to expose a fully
compile-time type-safe way of invoking remote functions (actors). Here is
what we do in HPX (https://github.com/STEllAR-GROUP/hpx/):

    int foo(std::string s) { return boost::lexical_cast<int>(s); }

    typedef hpx::make_action<decltype(&foo), &foo>::type foo_action_type;
    foo_action_type foo_action;

    // 'synchronous' invocation
    cout << foo_action(remote_locality_id, "42");       // prints 42

    // asynchronous invocation
    hpx::future<int> f = hpx::async(foo_action, remote_locality_id, "42");
    // do other stuff
    cout << f.get();       // prints 42

    // fails compiling
    cout << foo_action(remote_locality_id, 42);

The same (similar) works for invoking member functions of remote objects.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu