@@ -23,17 +23,6 @@ It is not possible to transfer a handle to a response to another actor.
...
@@ -23,17 +23,6 @@ It is not possible to transfer a handle to a response to another actor.
\end{itemize}
\end{itemize}
\subsection{Sending Messages}
\begin{itemize}
\item
\lstinline^send(whom, ...)^ is defined as \lstinline^send_tuple(whom, make_message(...))^.
Hence, a message sent via \lstinline^send(whom, self->last_dequeued())^ will not yield the expected result, since it wraps \lstinline^self->last_dequeued()^ into another \lstinline^message^ instance.
The correct way of forwarding messages is \lstinline^self->forward_to(whom)^.
@@ -11,42 +11,115 @@ Hence, we provide an internal domain-specific language to match incoming message
...
@@ -11,42 +11,115 @@ Hence, we provide an internal domain-specific language to match incoming message
\subsection{Basics}
\subsection{Basics}
\label{Sec::PatternMatching::Basics}
\label{Sec::PatternMatching::Basics}
A match expression begins with a call to the function \lstinline^on^, which returns an intermediate object providing \lstinline^operator>>^.
Actors can store a set of message callbacks using either \lstinline^behavior^ or \lstinline^message_handler^.
The right-hand side of the operator denotes a callback, usually a lambda expression, that should be invoked if a tuple matches the types given to \lstinline^on^,
The difference between the two is that the former stores an optional timeout.
as shown in the example below.
The most basic way to define a pattern is to store a set of lambda expressions using one of the two container types.
\begin{lstlisting}
\begin{lstlisting}
on<int>() >> [](int i) { /*...*/ }
behavior bhvr1{
on<int, float>() >> [](int i, float f) { /*...*/ }
[](int i) { /*...*/ },
on<int, int, int>() >> [](int a, int b, int c) { /*...*/ }
[](int i, float f) { /*...*/ },
[](int a, int b, int c) { /*...*/ }
};
\end{lstlisting}
\end{lstlisting}
The result of \lstinline^operator>>^ is a \textit{match statement}.
In our first example, \lstinline^bhvr1^ models a pattern accepting messages that consist of either exactly one \lstinline^int^, or one \lstinline^int^ followed by a \lstinline^float^, or three \lstinline^int^s.
A message handler can consist of any number of match statements.
Any other message is not matched and will remain in the mailbox until it is consumed eventually.
At most one callback is invoked, since the evaluation stops at the first match.
This caching mechanism allows actors to ignore messages until a state change replaces its message handler.
However, this can lead to a memory leak if an actor receives messages it handles in no state.
To allow actors to specify a default message handlers for otherwise unmatched messages, \lib provides the function \lstinline^others()^.
\begin{lstlisting}
\begin{lstlisting}
message_handler fun {
behavior bhvr2{
on<int>() >> [](int i) {
[](int i) { /*...*/ },
// case1
[](int i, float f) { /*...*/ },
[](int a, int b, int c) { /*...*/ },
others() >> [] { /*...*/ }
};
\end{lstlisting}
Please note the change in syntax for the default case.
The lambda expression passed to the constructor of \lstinline^behavior^ is prefixed by a ''match expression'' and the operator \lstinline^>>^.
\subsection{Atoms}
\label{Sec::PatternMatching::Atoms}
Assume an actor provides a mathematical service for integers.
It takes two arguments, performs a predefined operation and returns the result.
It cannot determine an operation, such as multiply or add, by receiving two operands.
Thus, the operation must be encoded into the message.
The Erlang programming language introduced an approach to use non-numerical
constants, so-called \textit{atoms}, which have an unambiguous, special-purpose type and do not have the runtime overhead of string constants.
Atoms are mapped to integer values at compile time in \lib.
This mapping is guaranteed to be collision-free and invertible, but limits atom literals to ten characters and prohibits special characters.
Legal characters are ``\lstinline[language=C++]^_0-9A-Za-z^'' and the whitespace character.
Atoms are created using the \lstinline^constexpr^ function \lstinline^atom^, as the following example illustrates.
\begin{lstlisting}
atom_value a1 = atom("add");
atom_value a2 = atom("multiply");
// ...
\end{lstlisting}
\textbf{Warning}: The compiler cannot enforce the restrictions at compile time, except for a length check.
The assertion \lstinline^atom("!?") != atom("?!")^ is not true, because each invalid character is mapped to the whitespace character.
An \lstinline^atom_value^ alone does not help us statically annotate function handlers.
To accomplish this, \lib offers compile-time \emph{atom constants}.
\begin{lstlisting}
using add_atom = atom_constant<atom("add")>;
using multiply_atom = atom_constant<atom("multiply")>;
\end{lstlisting}
Using the constants, we can now define message passing interfaces in a convenient way.
\begin{lstlisting}
behavior do_math{
[](add_atom, int a, int b) {
return a + b;
},
},
on<int>() >> [](int i) {
[](multiply_atom, int a, int b) {
// case2; never invoked, since case1 always matches first
return a * b;
}
}
};
};
\end{lstlisting}
\end{lstlisting}
The function ``\lstinline^on^'' can be used in two ways.
Atom constants define a static member \lstinline^value^ that can be used on the caller side (see Section \ref{Sec::Send}), e.g., \lstinline^send(math_actor, add_atom::value, 1, 2)^.
Please note that the static \lstinline^value^ member does \emph{not} have the type \lstinline^atom_value^, unlike \lstinline^std::integral_constant^ for example.
\clearpage
\subsection{Match Expressions}
Match expressions are an advanced feature of \lib and allow you to match on values and to extract data while matching.
Using lambda expressions and atom constants---cf. \ref{Sec::PatternMatching::Atoms}---suffices for most use cases.
A match expression begins with a call to the function \lstinline^on^, which returns an intermediate object providing \lstinline^operator>>^.
The function \lstinline^others()^ is an alias for \lstinline^on<anything>()^.
The right-hand side of the operator denotes a callback, usually a lambda expression, that should be invoked if a tuple matches the types given to \lstinline^on^,
When using the basic syntax, \lib generates the match expression automatically.
A verbose version of the \lstinline^bhvr1^ from \ref{Sec::PatternMatching::Basics} is shown below.
\begin{lstlisting}
behavior verbose_bhvr1{
on<int>() >> [](int i) { /*...*/ },
on<int, float>() >> [](int i, float f) { /*...*/ },
on<int, int, int>() >> [](int a, int b, int c) { /*...*/ }
};
\end{lstlisting}
The function \lstinline^on^ can be used in two ways.
Either with template parameters only or with function parameters only.
Either with template parameters only or with function parameters only.
The latter version deduces all types from its arguments and matches for both type and value.
The latter version deduces all types from its arguments and matches for both type and value.
To match for any value of a given type, ``\lstinline^val^'' can be used, as shown in the following example.
To match for any value of a given type, the template \lstinline^val<T>^ can be used, as shown in the following example.
\subsection{Reducing Redundancy with ``\lstinline^arg_match^'' and ``\lstinline^on_arg_match^''}
To avoid redundancy when working with match expressions, \lstinline^arg_match^ can be used as last argument to the function \lstinline^on^.
This causes the compiler to deduce all further types from the signature of any given callback.
Our previous examples always used the most verbose form, which is quite redundant, since you have to type the types twice -- as template parameter and as argument type for the lambda.
To avoid such redundancy, \lstinline^arg_match^ can be used as last argument to the function \lstinline^on^.
This causes the compiler to deduce all further types from the signature of the given callback.
\begin{lstlisting}
\begin{lstlisting}
on<int, int>() >> [](int a, int b) { /*...*/ }
on<int, int>() >> [](int a, int b) { /*...*/ }
...
@@ -72,38 +142,9 @@ on<int, int>() >> [](int a, int b) { /*...*/ }
...
@@ -72,38 +142,9 @@ on<int, int>() >> [](int a, int b) { /*...*/ }
on(arg_match) >> [](int a, int b) { /*...*/ }
on(arg_match) >> [](int a, int b) { /*...*/ }
\end{lstlisting}
\end{lstlisting}
Note that the second version does call \lstinline^on^ without template parameters.
Note that \lstinline^arg_match^ must be passed as last parameter.
Furthermore, \lstinline^arg_match^ must be passed as last parameter.
If all types should be deduced from the callback signature, \lstinline^on_arg_match^ can be used, which is an alias for \lstinline^on(arg_match)^.
If all types should be deduced from the callback signature, \lstinline^on_arg_match^ can be used.
However, \lstinline^on_arg_match^ is used implicitly whenever a callback is used without preceding match expression.
It is equal to \lstinline^on(arg_match)^.
However, when using a pattern to initialize the behavior of an actor, \lstinline^on_arg_match^ is used implicitly whenever a functor is passed without preceding it with an \lstinline^on^ clause.
Messages can be delayed, e.g., to implement time-based polling strategies, by using one of \lstinline^delayed_send^, \lstinline^delayed_send_tuple^, \lstinline^delayed_reply^, or \lstinline^delayed_reply_tuple^.
Messages can be delayed by using the function \lstinline^delayed_send^.
The following example illustrates a polling strategy using \lstinline^delayed_send^.
A synchronous message is sent to the receiving actor's mailbox like any other asynchronous message.
A synchronous message is sent to the receiving actor's mailbox like any other (asynchronous) message.
The response message, on the other hand, is treated separately.
The response message, on the other hand, is treated separately.
The difference between \lstinline^sync_send^ and \lstinline^timed_sync_send^ is how timeouts are handled.
The difference between \lstinline^sync_send^ and \lstinline^timed_sync_send^ is how timeouts are handled.
The behavior of \lstinline^sync_send^ is analogous to \lstinline^send^, i.e., timeouts are specified by using \lstinline^after(...)^ statements (see \ref{Sec::Receive::Timeouts}).
The behavior of \lstinline^sync_send^ is analogous to \lstinline^send^, i.e., timeouts are specified by using \lstinline^after(...)^ statements (see Section \ref{Sec::Receive::Timeouts}).
When using \lstinline^timed_sync_send^ function, \lstinline^after(...)^ statements are ignored and the actor will receive a \lstinline^sync_timeout_msg^ after the given duration instead.
When using \lstinline^timed_sync_send^ function, \lstinline^after(...)^ statements are ignored and the actor will receive a \lstinline^sync_timeout_msg^ after the given duration instead.
\subsection{Error Messages}
\subsection{Error Messages}
...
@@ -46,7 +39,7 @@ When sending a synchronous message, the response handler can be passed by either
...
@@ -46,7 +39,7 @@ When sending a synchronous message, the response handler can be passed by either
\begin{lstlisting}
\begin{lstlisting}
void foo(event_based_actor* self, actor testee) {
void foo(event_based_actor* self, actor testee) {
// testee replies with a string to 'get'
// testee replies with a string to 'get'
self->sync_send(testee, atom("get")).then(
self->sync_send(testee, get_atom::value).then(
[=](const std::string& str) {
[=](const std::string& str) {
// handle str
// handle str
},
},
...
@@ -82,7 +75,7 @@ void foo(event_based_actor* self, actor testee) {
...
@@ -82,7 +75,7 @@ void foo(event_based_actor* self, actor testee) {