[erlang-questions] gen_statem confusion

[Fred Hebert]

On 01/18, Vans S wrote:

>Example:
>
>handle_event(timeout, _, _, _) ->
>    long_running_func(),
>    %a proc sends to us send(self(), msg)
>    {next_event, internal, next_state},
>    %OR
>
>    {next_state, next_state, no_data, 0}.
>
>We want to proc the next_state event/timeout befor handing the msg msg 
>we got
>from a random process.

The {next_state, StateName, Data, Actions} form allows `Actions' to be 
one or more of:

- `postpone', which will replay the current event on the next state 
  transition and skip it for now. This one has to do with replicating a 
  selective receive
- `{next_event, EventType, EventContent}', which will enqueue the 
  generated event as the next one to run no matter what, unless other 
  events were already enqueued with the {next_event, ...} action 
  beforehand. This is a mechanism to allow self-driving state machines 
  with event injection without losing the ability to trace or handle 
  calls from the sys module (i.e. the state machine does not become 
  unresponsive)
- 'enter action' events, related to handling state transitions. Those 
  include timeouts (generate a message if no event has been received in 
  a while), state timeouts (generate a message if no state transition 
  has happened in a while), and asking for hibernation. Those have to do 
  with handling the behaviour of the process between events or state 
  transitions.
- replying to a process that has previously sent a synchronous call

So if you want the next event run internally to be 'next_state' (which I 
assume means "progress to the next state" in your state machine), you'd 
need to return:

handle_event(timeout, _TimeoutMsg, StateName, Data) ->
    ...
    {next_state, StateName, Data, [{next_event, internal, next_state}]}.

which will enqueue 'next_state' as an internally-generated message to be 
handled.

Regards,
Fred.