[erlang-questions] gen_statem state enter call and changing t oanother state

[Ingela Andin]

Hi!

Then I think it sounds like you could have a help function to call when you
leave the previous states to determine what should be the next state so
that you make the "TM" right transition in the first place.
Or what am I not understanding?

Regards Ingela Erlang/OTP team Ericsson AB


2018-06-12 14:14 GMT+02:00 Frans Schneider <fchschneider@REDACTED>:

>
>
> On 06/12/2018 12:31 PM, Ingela Andin wrote:
>
>> Hi!
>>
>> Could it be so that you are trying to solve the problem in the wrong
>> place? State enter actions are good for example starting a timer, but I
>> think it is illogical to change the state.
>> It sound to me like you could do so pattern matching, maybe in
>> conjunction with some guards in the your state function clauses and if your
>> conditions are meet maybe
>> all that clause does is to change state.
>>
>> Regards Ingela Erlang/OTP team - Ericsson AB
>>
>>
>>
> Of course I can, but in this particular case it would lead to simpler
> code. For example, I have the following state changes defined ([1] par.
> 8.4.12.2):
>
> __|_____________|_____________________________|____________________
> T2|waiting      |HEARTBEAT message is received|if (HB.FinalFlag ==
>   |             |                             |    NOT_SET) then
>   |             |                             |  must_send_ack else if
>   |             |                             |   (HB.LivelinessFlag ==
>   |             |                             |   NOT_SET) then
>   |             |                             |  may_send_ack
>   |             |                             |else
>   |             |                             |  waiting
> __|_____________|_____________________________|____________________
> T3|may_send_ack |GuardCondition:              |waiting
>   |             |   WP::missing_changes() ==  |
>   |             |       <empty>               |
> __|_____________|_____________________________|____________________
> T4|may_send_ack |GuardCondition:              |must_send_ack
>   |             |   WP::missing_changes() !=  |
>   |             |       <empty>               |
> __|_____________|_____________________________|____________________
> T5|must_send_ack|after(R::heartbeatResponseDelay) waiting
> __|_____________|_____________________________|____________________
>
> Transitions T3/T4 are just begging for a enter state with next_state. The
> alternative would be to put the guard conditions at the end of T2, which of
> course is not that bad but it messes up the line of thinking of the
> original protocol designers and its readers. Also, T3/T4 could just become
> something like:
>
> handle_event(enter,
>              _Old_state,
>              #state{state2 = may_send_ack} = State,
>              #data{missing_changes = []} = Data) ->
>     {next_state, waiting, Data};
> handle_event(enter,
>              _Old_state,
>              #state{state2 = may_send_ack} = State,
>              Data) ->
>     ...
>     {next_state, must_send_ack, Data};
>
> which I think is very accurate. In the example, there is only T2 as the
> old state but there are other examples with more than one originating
> states.
>
> Frans
>
> [1] https://www.omg.org/spec/DDSI-RTPS/2.2/PDF
>
>
>> 2018-06-12 10:31 GMT+02:00 Frans Schneider <fchschneider@REDACTED
>> <mailto:fchschneider@REDACTED>>:
>>
>>
>>
>>     On 06/12/2018 10:06 AM, Raimo Niskanen wrote:
>>
>>
>>         I agree.  State enter calls were introduced to allow code to be
>>         run when a
>>         state is entered, without having to duplicate that code at every
>>         state exit
>>         from the previous state.  It is a feature existing in other
>>         state machine
>>         description languages e.g OpenBSD's ifstated.
>>
>>     This is the exact reason for bringing up the whole issue. And
>>     sometimes, that requires a next_state NewState.
>>
>>
>>
>>     Frans
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>>     <http://erlang.org/mailman/listinfo/erlang-questions>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180612/bca9afcc/attachment.htm>