{"id":404857,"date":"2024-06-29T17:58:18","date_gmt":"2024-06-29T17:58:18","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=404857"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=404857","title":{"rendered":"What’s new in rotor v0.09<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

\"actor<\/p>\n

<\/p>\n

rotor<\/a> is a non-intrusive<\/a> event loop friendly C++ actor micro framework, similar to its elder brothers like caf<\/a> and sobjectizer<\/a>. The new release came out under the flag of pluginization<\/strong>, which affects the entire lifetime of an actor.<\/p>\n

<\/a> <\/p>\n

Actor Linking<\/h2>\n

<\/p>\n

The actor system is all about interactions between actors, i.e. sending messages to each other (and producing side effects for the outer world or listening to messages it produces). However, to let a message be delivered to the final actor, the actor should be alive<\/strong> (1); in other words, if actor A<\/code> is going to send message M<\/code> to actor B<\/code>, A<\/code> should somehow be sure that actor B<\/code> is online and will not go offline while M<\/code> is routing.<\/p>\n

<\/p>\n

Before rotor<\/a> v0.09<\/code>, that kind of warranty was only available due to child-parent relations, i.e. between supervisor and its child-actor. In this case, an actor was guaranteed that a message would be delivered to its supervisor because the supervisor owned<\/em> the actor and said supervisor’s lifetime covered the respective actor’s lifetime. Now, with the release of v0.09<\/code>, it is possible to link actor A<\/code> with actor B<\/code> that are not parent- or child-related to one another and to make sure that all messages will be delivered after successful linking .<\/p>\n

<\/p>\n

So, linking actors is performed somewhat along these lines:<\/p>\n

<\/p>\n

namespace r = rotor;  void some_actor_t::on_start() noexcept override {     request<payload::link_request_t>(b_address).send(timeout); }  void some_actor_t::on_link_response(r::message::link_response_t &response) noexcept {     auto& ec = message.payload.ec;     if (!ec) {         \/\/ successful linking     } }<\/code><\/pre>\n
  <\/p>\n
However, code like this should not be used directly as is\u2026 because it is inconvenient. It becomes more obvious if you try linking actor A<\/code> with 2 or more actors (B1<\/code>, B2<\/code>, etc.), since some_actor_t<\/code> should keep an internal count of how many target actors are waiting for (successful) link responses. And here the pluginization system featured in the v0.09<\/code> release comes to the rescue:<\/p>\n
  <\/p>\n
namespace r = rotor;  void some_actor_t::configure(r::plugin::plugin_base_t &plugin) noexcept override {     plugin.with_casted<r::plugin::link_client_plugin_t>(         [&](auto &p) {             p.link(B1_address);             p.link(B2_address);         }     ); }<\/code><\/pre>\n
  <\/p>\n
Now, this is much more convenient, since link_client_plugin_t<\/code> is included out of the box with the rotor::actor_base_t<\/code>. Nevertheless, it’s still not enough, because it does not answer a few important questions, such as: 1. When is actor linking performed (and a «by-question»: when is actor unlinking<\/strong> performed)? 2. What happens if the target actor (aka «server») does not exist or rejects linking? 3. What happens if the target actor decides to self-shutdown when there are «clients» still linked to it?<\/p>\n
  <\/p>\n
To provide answers to these questions, the concept of actor lifetime should be revisited.<\/p>\n
  <\/p>\n
Async Actor Initialization And Shutdown<\/h2>\n
  <\/p>\n
Represented in a simplified manner is, here is how an actor\u2019s state usually changes: new<\/code> (constructor) -> initializing<\/code> -> initialized<\/code> -> operational<\/code> -> shutting down<\/code> -> shut down<\/code><\/p>\n
  <\/p>\n
The main job is performed in the operational<\/code> state, and it is up to the user to define what an actor is to do in its up-and-running mode.<\/p>\n
  <\/p>\n
In the I-phase<\/strong> (i.e. initializing<\/code> -> initialized<\/code>), the actor should prepare itself for further functioning: locate and link with other actors, establish connection to the database, acquire whichever resources it needs to be operational. The key point of rotor<\/a> is that I-phase is asynchronous<\/strong>, so an actor should notify its supervisor when it is ready (2).<\/p>\n
  <\/p>\n
The S-phase<\/strong> (i.e. shutting down<\/code> -> shut down<\/code>) is complementary to the I-phase<\/strong>, i.e. the actor is being asked to shut down, and, when it is done, it should notify its supervisor.<\/p>\n
  <\/p>\n
While it sounds easy, the tricky bit lies in the composability<\/strong> of actors, when they form Erlang-like hierarchies of responsibilities (see my article on trees of Supervisors<\/a>). In other words, any actor can fail during its I-phase<\/code> or S-phase<\/code>, and that can lead to asynchronous collapse of the entire hierarchy, regardless of the failed actor’s location within it. Essentially, the entire hierarchy of actors becomes operational<\/code>, or, if something happens, the entire hierarchy becomes shut down<\/code>.<\/p>\n
  <\/p>\n
rotor<\/a> seems unique with its init\/shutdown approach. There is nothing similar in caf<\/a>;
  in sobjectizer<\/a>, there is a shutdown helper<\/a>, which
  carries a function similar to the S-phase<\/code> above; however, it is limited to one actor only and offers no I-phase<\/code> because sobjectizer<\/a> has no concept of hierarchies (see update<\/strong> below).<\/p>\n
  <\/p>\n
While using rotor<\/a>, it was discovered that the progress of the I-phase<\/code> (S-phase<\/code>) may potentially require many<\/em> resources to be acquired (or released) asynchronously, which means that no single component, or actor, is able, by its own will, to answer the question of whether it has or has not completed the current phase. Instead, the answer comes as a result of collaborative efforts, handled in the right order. And this is where plugins<\/strong> come into play; they are like pieces, with each one responsible for a particular job of initialization\/shutdown.<\/p>\n
  <\/p>\n
So, here are the promised answers related to link_client_plugin_t<\/code>:<\/p>\n
  <\/p>\n