gen_statem next_event and appending to the event queue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

gen_statem next_event and appending to the event queue

Frans Schneider-2
Dear list,

I have a state machine which implements the RTPS reader locator [1].
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
action for this as well, which looks tidier and feels better. What about
adding an action {add_event, EventType, EventContent}?

Frans

[1] http://www.omg.org/spec/DDSI-RTPS/2.2/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_statem next_event and appending to the event queue

Raimo Niskanen-2
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].
> 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
> 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.

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

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_statem next_event and appending to the event queue

Frans Schneider-2
In reply to this post by Frans Schneider-2
 > 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].
 >> 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
 >> 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.

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
events, it would still process the can_send events before the (re)set
events which are external.

 >
 >>
 >> Frans
 >>
 >> [1] http://www.omg.org/spec/DDSI-RTPS/2.2/
 >
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_statem next_event and appending to the event queue

Raimo Niskanen-2
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
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions