Event processed before entry

[redboltz]

Thanks to fix #94, I can write sm.process_event() in action.

I implement the following code:

#include <iostream>
#include <boost/sml.hpp>

namespace sml = boost::sml;

struct e1 {};

struct Table {
    auto operator()() const noexcept {
        using namespace sml;
        return make_transition_table(
            *"s1"_s + on_entry<sml::initial> / [](const auto& /*ev*/, auto& sm) {
                sm.process_event(e1());
                std::cout << "code after sm.process_event(e1());" << std::endl;
            } = "s2"_s
            ,"s1"_s + event<e1> / [] { std::cout << "s1::e1 unexpected" << std::endl; }
            ,"s2"_s + on_entry<_> / [] { std::cout << "s2::entry" << std::endl; }
            ,"s2"_s + event<e1> / [] { std::cout << "s2::e1" << std::endl; }
        );
    }
};

int main() {
    sml::sm<Table> sm;
}

I got the following output:

s2::e1
code after sm.process_event(e1());
s2::entry

Expected output is

code after sm.process_event(e1());
s2::entry
s2::e1

Here is running demo:
https://wandbox.org/permlink/r4NIXXnS1SvlCpN4 (sml is nightly updated.)

It seems that sm.process_event(e1()); processed immediately. I believe that actual invokeing e1 should defer until state changes to s2.

It might relate to #96.

[DenizThatMenace]

The more general question that should be answered beforehand is probably this one:
Ignoring the case of process_event being called from within an action for now, what is the expected order of exit/entry/transition actions?

Running the following example shows the current order of actions.

#include <iostream>
#include <boost/sml.hpp>

namespace sml = boost::sml;

struct e1 {};

struct Table {
    auto operator()() const noexcept {
        using namespace sml;
        return make_transition_table(
            *"source"_s + on_exit<e1> / [] { std::cout << "exit source" << std::endl; }
            ,"target"_s + on_entry<e1> / [] { std::cout << "enter target" << std::endl; }
            ,"source"_s + event<e1> / [] { std::cout << "during transition" << std::endl; } = "target"_s
        );
    }
};

int main() {
    sml::sm<Table> sm;
    sm.process_event(e1());
}

It prints

exit source
during transition
enter target

However, is this the desired and correct order? Or should it be the following?

exit source
enter target
during transition

And what happens if an exception occurs during the actions of the transitions after the source-state was left but before the target-state was entered. In what state will the state-machine be in?

[redboltz]

@Bagira80 ,

exit source
during transition
enter target

is desired order. Because it is defined by UML2.x spec.
See http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF

---

Page 561

• entry: Behavior[0..1]
  An optional behavior that is executed whenever this state is entered regardless of the transition taken to reach the state. If defined, entry actions are always executed to completion prior to any internal behavior or transitions performed within the state. {Subsets Element::ownedElement}
• exit: Behavior[0..1]
  An optional behavior that is executed whenever this state is exited regardless of which transition was taken out of the state. If defined, exit actions are always executed to completion only after all internal activities and transition actions have completed execution. {Subsets Element::ownedElement}

Page 581

• effect: Behavior[0..1]
  Specifies an optional behavior to be performed when the transition fires.

Page 585

Once a transition is enabled and is selected to fire, the following steps are carried out in order:

• The main source state is properly exited.
• Behaviors are executed in sequence following their linear order along the segments of the transition: The closer the behavior to the source state, the earlier it is executed.
• If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected.
• The main target state is properly entered.

---

In the context Behaviors are executed means transition's effect (action).

Boost.MSM behaves as follows too.

exit source
during transition
enter target

[DenizThatMenace]

@redboltz

Thank you, that makes it a little clearer for me. So the order of exit/entry/transition actions is correct then. This is good. :-)

However, something which might be interesting (particular with #115) is when the state-change takes place. Boost.MSM has a policy for that: http://www.boost.org/doc/libs/1_64_0/libs/msm/doc/HTML/ch03s05.html#d0e2714

Coming back to your originally mentioned problem, you seem to be correct.

Although the meaning of process_event seems to be correct, to synchronously process it. I would instead expect another function enqueue_event which should be used from within the action instead.
It would enqueue that event without processing it directly and return. The event would then be processed automatically after the current transition finished (including state-change and entry-action of the target-state).
Several enqueued events would have to be processed in FIFO order.

This sounds pretty much as if defered events is the mechanism we are looking for. (However, I am not sure how to apply it from within an action.)

[redboltz]

It might be a off topic, but might useful to understand the state transition point.

+-----------------------+         +-----------------------+
|        S1             |         |        S2             |
| on_exit               |         | on_entry              |
|                       |         |                       |
|  +----------------+   |         |  +----------------+   |
|  |     S1_1       |   |         |  |     S2_1       |   |
|  | on_exit        |   |         |  | on_entry       |   |
|  |                |   |         |  |                |   |
|  |  +----------+  |   |  e[g]/a |  |                |   |
|  |  |  S1_1_1  |------------------>|                |   |
|  |  | on_exit  |  |   |         |  |                |   |
|  |  +----------+  |   |         |  |                |   |
|  |                |   |         |  |                |   |
|  |                |   |         |  |                |   |
|  +----------------+   |         |  +----------------+   |
|                       |         |                       |
+-----------------------+         +-----------------------+

Let's say the current state is S1_1_1, the parant states are S1_1, and S1. When event e occur, then the guard 'g' is checked. During guard checking, the current state is S1_1_1. If g is satisfied, then S1_1_1's on_exit is invoked. In the on_exit handler, the current state is still S1_1_1. When the handler is finished, I think the the current state is no longer S1_1_1, but still parant states are S1_1 and S1. Then S1_1's on_exit in invoked, similarly the current state is S1. Then S1's on_exit is invoked. The current state is a kind of no state. If S1 and S2 are containd by something like root state, the parant state is root state. Then the action a, is invoked. In the action a handler, AFAIK, UML doesn't give the definition of the current state is S1, S2, or none. So Boost.MSM provides the policy to switch the behavior. After the action a is invoked, enter S2 and S2's on_entry is invoked. Finally, S2_1's on_entry is invoked.

By the way, the following diagram smantically the same as the above one. So the action a should be invoked the outer most state.

+----------------------------+         +--------------------+
|        S1                  |         |        S2          |
| on_exit                    |         | on_entry           |
|                            |         |                    |
|  +---------------------+   |         |     +----------+   |
|  |     S1_1            |   |         |     |     S2_1 |   |
|  | on_exit             |   |         |     | on_entry |   |
|  |                     |   |         |     |          |   |
|  |  +----------+ e[g]/a|   |         |     |          |   |
|  |  |  S1_1_1  |-------------------------->|          |   |
|  |  | on_exit  |       |   |         |     |          |   |
|  |  +----------+       |   |         |     |          |   |
|  |                     |   |         |     |          |   |
|  |                     |   |         |     |          |   |
|  +---------------------+   |         |     +----------+   |
|                            |         |                    |
+----------------------------+         +--------------------+

Howeverm it is a little confusing. So Boost.MSM doesn't recomment those kind of transition, direct transition. AFAIK, SML doesn't support it.

If we want to do the those kinds of transtion, we can use x exit point pseudo state and o entry point pseudo state.

+----------------------------+         +--------------------+
|        S1                  |         |        S2          |
| on_exit                    |         | on_entry           |
|                            |         |                    |
|  +---------------------+   |         |     +----------+   |
|  |     S1_1            |   |         |     |     S2_1 |   |
|  | on_exit             |   |         |     | on_entry |   |
|  |                     |   |         |     |          |   |
|  |  +----------+e[g]/a1|/a2|  /a3    |/a4  |          |   |
|  |  |  S1_1_1  |-------x---x---------o---->|          |   |
|  |  | on_exit  |       |   |         |     |          |   |
|  |  +----------+       |   |         |     |          |   |
|  |                     |   |         |     |          |   |
|  |                     |   |         |     |          |   |
|  +---------------------+   |         |     +----------+   |
|                            |         |                    |
+----------------------------+         +--------------------+

The action order is S1_1_1 on_exit, a1, S1_1 on_exit, a2, S1 on_exit, a3, S2 on_entry, a4, and S2_1 on_entry.

[redboltz]

Although the meaning of process_event seems to be correct, to synchronously process it. I would instead expect another function enqueue_event which should be used from within the action instead.

https://github.com/boostorg/msm/blob/develop/include/boost/msm/back/state_machine.hpp#L2006
Boost.MSM's process_event called process_event_internal, internally. If process_event calls at out of the MSM, e.g. int main(), invokes event immediately. If process_event calls in the MSM, e.g. some action handler, then process event enque the event, doesn't invoke immediately. The event will invoke after other queued events are invoked. It is a FIFO order.

It would enqueue that event without processing it directly and return. The event would then be processed automatically after the current transition finished (including state-change and entry-action of the target-state).
Several enqueued events would have to be processed in FIFO order.

This sounds pretty much as if defered events is the mechanism we are looking for. (However, I am not sure how to apply it from within an action.)

I agree. I really want to have the functionality you mentioned too.

We have the subtle difference the name of process_event or post(enque)_event, but I think that it is not essential issue.

[kris-jusiak]

Thanks, @redboltz and @Bagira80 . It should be fixed by #156.

test queue_process_reaction = [] {
  struct c {
    auto operator()() noexcept {
      using namespace sml;
      // clang-format off
      return make_transition_table(
        * s1 + on_entry<sml::initial> / [this] { calls += "s1e|"; }
        , s1 + event<e1> / [this](sml::back::process<e2, e3> process_event) {
            calls += "a1.begin|";
            process_event(e2{});
            process_event(e3{});
            calls += "a1.end|";
          }
         , s1 + event<e2> / [this] { calls += "a2|"; }
         , s2 + event<e3> / [this] { calls += "a3|"; }
         , s1 + unexpected_event<e3> / [this] { calls += "err|"; } = X
      );
      // clang-format on
    }

    std::string calls{};
  };

  sml::sm<c, sml::process_queue<std::queue>> sm{};

  sm.process_event(e1());
  expect(sm.is(sml::X));

  const c& c_ = sm;
  expect("s1e|a1.begin|a1.end|a2|err|" == c_.calls);
};

[redboltz]

@krzysztof-jusiak , thank you!

I double checked the fix. I got the expected result.

https://wandbox.org/permlink/bONB5FtM1GCacllX

#include <iostream>
#include <queue>
#include <boost/sml.hpp>

namespace sml = boost::sml;

struct e1 {};

struct Table {
    auto operator()() const noexcept {
        using namespace sml;
        return make_transition_table(
            *"s1"_s + on_entry<sml::initial> / [](const auto& /*ev*/, sml::back::process<e1> process_event) {
                process_event(e1());
                std::cout << "code after sm.process_event(e1());" << std::endl;
            } = "s2"_s
            ,"s1"_s + event<e1> / [] { std::cout << "s1::e1 unexpected" << std::endl; }
            ,"s2"_s + on_entry<_> / [] { std::cout << "s2::entry" << std::endl; }
            ,"s2"_s + event<e1> / [] { std::cout << "s2::e1" << std::endl; }
        );
    }
};

int main() {
    sml::sm<Table, sml::process_queue<std::queue>> sm;
}

Output:

code after sm.process_event(e1());
s2::entry
s2::e1