Timer and thread support

[andzsinszan]

First of all, thanks for this wonderful project!
I am coming from SCXML background, so my questions may seem either trivial or nonsensical.

• What would be the standard way in HFSM2 to start at timer? (e.g. manually start an event-triggering lambda in a thread? Or is there some built-in support?)
• Somewhat related: is event processing thread-safe, or is this responsibility delegated to the library user/caller code?

[andrew-gresyk]

My pleasure, glad you like it!

Timers

In general, HFSM2 and FFSM2 focus only on state transitions, and provide the tools for the user to implement the supporting infrastructure, be those timers or threads.

For examples of event handling please see:

• https://github.com/andrew-gresyk/HFSM2/blob/master/examples/snippets/wiki_tutorial.cpp#L131
• https://github.com/andrew-gresyk/HFSM2/blob/master/examples/advanced_event_handling/main.cpp#L183

It boils down to adding react(const TimerEvent&, FullControl&) method to the state, that's expected to handle it:

struct TimerEvent {}; // can be any type, even bool / char / int / etc.

struct ConcreteHandler
	: FSM::State
{
	// handle two event types - PrimaryEvent
	void react(const TimerEvent&, FullControl&) {
		// implement
	}

	// if you have more than one event but only handle one in this state, be sure to add this line:
	using FSM::State::react;
};

.. and triggering it from your timer callback:

// ..
FSM::Instance machine;
// ..

void TimerProc(..) {
	machine.react(TimerEvent{});
}

One thing to be mindful of, is react<>() might trigger state transition(s), causing more code to be executed on the 'wrong' thread.

E.g. in my UE4 toy project, I needed to trigger delegates in states' enter() / exit() methods.
For that to work correctly, I had enter() / exit() only record the delegate details, and actually trigger them in bulk in the appropriate AActor::update().

Thread safety (or the lack thereof)

HFSM2 isn't thread safe.
It's up to the user to provide the necessary synchronization.

[andrew-gresyk]

I'm not super familiar with STL threading facilities, but that looks reasonable.
Could you share a minimal working example that I can build and debug locally?

[andzsinszan]

Sure, no problem, I forked the repo and added the example with event loop.
https://github.com/pinlab/HFSM2
examples/event_loop/CMakeLists.txt

[andrew-gresyk]

It's looking good, and seems to be working.
Do you have any concerns about it?

[andzsinszan]

For timers and threads all is clear, thank you. The discussion can be closed.

Marginally related question, concerning this piece from Your post:

// if you have more than one event but only handle one in this state, be sure to add this line:
using FSM::State::react;

It works as advertised, but I don't completely see how. I guess this "introduces" the templated version of react from the parent struct (see below) to the actual state struct. But how does this without template parameters? Some pointers about the mechanism would be highly appreciated.

template <typename TEvent>
void react(const TEvent&, FullControl&) noexcept {}

[andrew-gresyk]

Cool.

That using statement is required for C++ template function overload resolution to work.

When the client code calls:

instance_.react(ev);

.. the expectation is:

• if the user state wants to handle a particular even type, it provides the appropriate react(TEvent).

To achieve that, FSM::State has an empty version of event<TEvent>(), which (according to C++ specs) will be inaccessible if its descendent also provides an override of react(TEvent), as per the expectation above.

HFSM2 internals will try to call react(TEvent) on all active states, and for that to compile, the appropriate event<TEvent>() for all event types, that the FSM is expected to handle need to be accessible to be called on the user state.

That's why base class' event<TEvent>() needs to be pulled into user state's scope.

Alternatively, it's also ok to provide all possible event<TEvent>() for all events within the client state.
Usually that's more boilerplate, so using FSM::State::react; can be used to reduce the impact of this issue.