[erlang-questions] gen_statem next_event and appending to the event queue

Raimo Niskanen raimo+erlang-questions@REDACTED
Wed Oct 4 15:23:26 CEST 2017

On Wed, Oct 04, 2017 at 01:28:59PM +0200, Frans Schneider wrote:
>  > On Wed, Oct 04, 2017 at 11:03:33AM +0200, Frans Schneider wrote:
>  >> Dear list,
>  >>
>  >> I have a state machine which implements the RTPS reader locator [1].

I do not have the time to read that.

>  >> Basically, it has a list of unsent changes which should be send one by
>  >> one to some transport. If the list is empty, the state becomes idle,
>  >> otherwise it keeps the state pushing and uses the state callback action
>  >> {next_event, internal, can_send} to process the next change from the 
> list.
>  >> However, the state machine also has to respond to some other events like
>  >> the one which will replace the list with unsent changes with a new one
>  >> (this is according to the specs.) But, since the callback action
>  >> next_event inserts events in front of the event queue, an event like
>  >> (re)setting the unsent changes list is only processed after all internal
>  >> events have been processed.
>  >> Adding events to the back of the queue can of course be done using a
>  >> gen_statem:cast or a simple '!', but I would like to use a callback

That would be processed after all queued events, and after all other
messages in the message queue.

>  >> action for this as well, which looks tidier and feels better. What about
>  >> adding an action {add_event, EventType, EventContent}?
>  >
>  > The gen_statem {next_event,,} event queue is not intended to solve all
>  > possible event queue problems, and in particular not intended to be a
>  > complete event execution model which would create a language within
>  > the language.  One may handle this with a specific queue in the state
>  > e.g with the module 'queue'.
>  >
>  > That said, there is a trick that might solve this problem, and that is to
>  > use a timeout 0.  It is guaranteed to be handled by the state machine
>  > before all external events.

That would be processed after all other queued events and before all
messages in the message queue.

> Actualy, I don't want the event _before_ the external events but just 
> added at the _end_ of the event queue. If I put it before external 

Yes. That is what will happen.

> events, it would still process the can_send events before the (re)set 
> events which are external.

... You lost me there ...

All events in the internal queue will be processed before the gen_statem
goes out and receives a new message.  And the last of these internal events
to process will be a timeout 0 event if there is any.

The message queue is not part of the event queue.

>  >
>  >>
>  >> Frans
>  >>
>  >> [1] http://www.omg.org/spec/DDSI-RTPS/2.2/
>  >


/ Raimo Niskanen, Erlang/OTP, Ericsson AB

More information about the erlang-questions mailing list