<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1474984041665_567800" dir="ltr"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567838"><br><br>> > </span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567839"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567840">> > If the implementation is quite simple using timers, I would not mind putting in the pull request. I just came here to discuss about it and see if it is something that fits.</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567841"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567842">> > </span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567843"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567844">> > The rational is using erlang:send_after/3 is not enough in more complex cases, we need to also be stopping and starting new timers. </span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567845"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567958">></span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567846"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567847">> Does not erlang:start_timer/3,4 work in this case? You can have any number</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567848"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_567849">> of such timers simultaneously running just as for erlang:send_after/3,4.<br></span><span id="yui_3_16_0_ym19_1_1474984041665_568031"><br>The example I gave was poor I forgot one key point and that was a case where cancel_timer was required. Say every scream resets your running. So every 500ms a scream event would return<br>[{timeout, 500,scream }, {timeout, 100, running_step}].<br><br>Using erlang:send_after we would have to cancel_timer on the running_step, also I am not sure how timers work, but if a function took long would a timer msg arrive in the mailbox? Thus cancel_timer would not work ideally? Say if the erlang:send_after is in 100ms, and we spend 200ms in a function then at the end of that function we call cancel_timer.<br><br><br></span></div><div id="yui_3_16_0_ym19_1_1474984041665_567800" dir="ltr"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568326">> Here is an attempt:</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568327"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568394">> </span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568328"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568329">> You return [{named_timeout,Time,Name}] and will get an event</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568330"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568331">> named_timeout,Name. If you return [{named_timeout,NewTime,Name}] with the</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568332"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568333">> Name of a running timer it will restart with NewTime. Therefore you can</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568334"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568335">> cancel it with [{named_timeout,infinity,Name}]. Any number of these can</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568336"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568337">> run simultaneously and you distinguish them by Name.</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568338"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568376">> </span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568339"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568340">> Or is the benefit of this i.e just to hide the TimerRef behind the timer</span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568341"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568342">> Msg/Name too small to be worthy of implementing?<br></span><span><br></span></div><div id="yui_3_16_0_ym19_1_1474984041665_567800" dir="ltr">I think the benefit is two fold, first is not managing cancel timer, and second is the code would be cleaner to read and reason about.<br><br>'infinity' as the timeout perhaps is misleading, could a new atom be introduced for this, perhaps cancel? <br>{timeout, cancel, scream}.<br><br>Crash if the scream timer is not initiated. If we cancel a timer that has to exist, we are in an undefined state.<br><br>'infinity' is fine for practicality purposes or the maximum value of a 56 bit integer (if that is the correct value before venturing into big Erlang integers).</div><div id="yui_3_16_0_ym19_1_1474984041665_567800" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1474984041665_567800" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1474984041665_567800" dir="ltr">What is the benefit of <span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568933">{named_timeout,Time,Name} vs the current </span><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1474984041665_568949">{timeout,Time,EventName}?</span><br><br><br></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Monday, October 3, 2016 5:45 AM, Raimo Niskanen <raimo+erlang-questions@erix.ericsson.se> wrote:<br></font></div> <br><br> <div class="y_msg_container">On Fri, Sep 30, 2016 at 02:25:13PM +0000, Vans S wrote:<br clear="none">> The reasoning behind this is because I am using a handle_event_function callback mode. I find this is more flexible. A standard state machine can be in 1 state at 1 time.<br clear="none">> <br clear="none">> But things are more complex now and the desire for a state machine to be in multiple states at 1 time is crucial. <br clear="none">> <br clear="none">> For example you can be running and screaming. Not only running then stopping to transition to screaming, then stop screaming and start running again.<br clear="none">> Maybe this is beyond the scope of a state machine, excuse if my terminology is off.<br clear="none"><br clear="none">I'd say that your state machine can only be in one state at any given time<br clear="none">but you have a complex state as in multi dimensional and each combination<br clear="none">of the different dimensions counts as a different state. So you have 4<br clear="none">discrete states: {not screaming, not running}, {not screaming, running},<br clear="none">{screaming, not running} and {screaming, running} but wants to reason about<br clear="none">the state as one complex term: {IsScreaming, IsRunning}.<br clear="none"><br clear="none">> <br clear="none">> If the implementation is quite simple using timers, I would not mind putting in the pull request. I just came here to discuss about it and see if it is something that fits.<br clear="none">> <br clear="none">> The rational is using erlang:send_after/3 is not enough in more complex cases, we need to also be stopping and starting new timers. <br clear="none"><br clear="none">Does not erlang:start_timer/3,4 work in this case? You can have any number<br clear="none">of such timers simultaneously running just as for erlang:send_after/3,4.<br clear="none"><br clear="none">> <br clear="none">> An example of this is say if we are in a running state and every 100 ms we timeout, when we timeout we take an extra step and update our position in the world, also we determine how fast we are running and maybe the next step will be in 80ms now.<br clear="none">> <br clear="none">> Now while we are running, we also got a moral boost by seeing a well lit street, so in 5000ms our moral boost will expire, and will timeout.<br clear="none">> <br clear="none">> Also we start screaming due to panic, every 500ms we send a scream to all nearby recipients.<br clear="none">> <br clear="none">> Maybe this is all beyond the scope of a state machine. But for me it seems the only change required to support this is allowing multiple timers, and Erlang always had the design philosophy of "do what works" vs "do what is academically sound".<br clear="none"><br clear="none">The question is if it is possible to create a timer concept in gen_statem<br clear="none">that is easier to use and still as flexible as erlang:start_timer/3,4 +<br clear="none">erlang:cancel_timer/1,2.<br clear="none"><br clear="none">With those primitives you have to handle the TimerRef yourself.<br clear="none"><br clear="none">Here is an attempt:<br clear="none"><br clear="none">You return [{named_timeout,Time,Name}] and will get an event<br clear="none">named_timeout,Name. If you return [{named_timeout,NewTime,Name}] with the<br clear="none">Name of a running timer it will restart with NewTime. Therefore you can<br clear="none">cancel it with [{named_timeout,infinity,Name}]. Any number of these can<br clear="none">run simultaneously and you distinguish them by Name.<br clear="none"><br clear="none">Or is the benefit of this i.e just to hide the TimerRef behind the timer<br clear="none">Msg/Name too small to be worthy of implementing?<br clear="none"><br clear="none">/ Raimo<div class="yqt7967896325" id="yqtfd25847"><br clear="none"><br clear="none"><br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> On Thursday, September 29, 2016 9:30 AM, Raimo Niskanen <raimo+<a shape="rect" ymailto="mailto:erlang-questions@erix.ericsson.se" href="mailto:erlang-questions@erix.ericsson.se">erlang-questions@erix.ericsson.se</a>> wrote:<br clear="none">> <br clear="none">> <br clear="none">> After giving this a second thought i wonder if a single state timer would<br clear="none">> be a desired feature and enough in your case.<br clear="none">> <br clear="none">> Today we have an event timeout, which is seldom useful since often you are<br clear="none">> in one state and wait for something specific while stray events that either<br clear="none">> are ignored or immediately replied to passes by. The event timeout is<br clear="none">> reset for every stray event.<br clear="none">> <br clear="none">> What I think would cover many use cases is a single state timeout. It<br clear="none">> would be cancelled if you change states. If you set it again the running<br clear="none">> timer is cancelled and a new is started. There would only need to be one<br clear="none">> such timer so it is roughly as easy to implement as the event timeout.<br clear="none">> <br clear="none">> There would be no way to cancel it other than changing states.<br clear="none">> It would be started with an action {state_timeout,T,Msg}.<br clear="none">> <br clear="none">> We should keep the old {timeout,T,Msg} since it is inherited from gen_fsm<br clear="none">> and has some use cases.<br clear="none">> <br clear="none">> What do you think?<br clear="none">> <br clear="none">> / Raimo<br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> On Mon, Sep 26, 2016 at 04:56:25PM +0200, Raimo Niskanen wrote:<br clear="none">> > On Sun, Sep 25, 2016 at 05:32:19PM +0000, Vans S wrote:<br clear="none">> > > Learning the new gen_statem made me desire for one extra feature.<br clear="none">> > > <br clear="none">> > > Say you have a common use case of a webserver /w websockets, you have a general connection timeout of 120s, if no messages are received in 120s it means the socket is in an unknown state, and should be closed.<br clear="none">> > > <br clear="none">> > > So you write your returns like this anytime the client sends you a message:<br clear="none">> > > <br clear="none">> > > {next_state, NextState, NewData, {timeout, 120*1000, idle_timeout}}<br clear="none">> > > <br clear="none">> > > Now if the client does not send any messages in 120 seconds, we will get a idle_timeout message sent to the gen_statem process.<br clear="none">> > > <br clear="none">> > > Awesome.<br clear="none">> > > <br clear="none">> > > But enter a little complexity, enter websockets.<br clear="none">> > > <br clear="none">> > > Now we need to send a ping from the gen_statem every 15s to the client, but we also need to consider if we did not get any messages from the client in 120s, we are in unknown state and should terminate the connection.<br clear="none">> > > <br clear="none">> > > So now we are just itching to do this on init:<br clear="none">> > > <br clear="none">> > > {ok, initial_state, Data, [ {timeout, 120*1000, idle_timeout}, {timeout, 15*1000, websocket_ping}<br clear="none">> > > ]}<br clear="none">> > > <br clear="none">> > > This way we do not need to manage our own timers using erlang:send_after. timer module is not even a consideration due to how inefficient it is at scaling.<br clear="none">> > > <br clear="none">> > > But of course we cannot do this, the latest timeout will always override any previous.<br clear="none">> > > <br clear="none">> > > What do you think?<br clear="none">> > <br clear="none">> > Your use case is in the middle ground between the existing event timeout<br clear="none">> > and using erlang:start_timer/4,3, and is a special case of using<br clear="none">> > erlang:start_timer/4,3.<br clear="none">> > <br clear="none">> > The existing {timeout,T,Msg} is an *event* timeout, so you get either an<br clear="none">> > event or the timeout. The timer is cancelled by the first event.<br clear="none">> > This semantics is easy to reason about and has got a fairly simple<br clear="none">> > implementation in the state machine engine partly since it only needs<br clear="none">> > to store one timer ref.<br clear="none">> > <br clear="none">> > It seems you could use a state timeout, i.e the timeout is cancelled when<br clear="none">> > the state changes. This would require the state machine engine to hold any<br clear="none">> > number of timer refs and cancel all during a state change.<br clear="none">> > <br clear="none">> > This semantics is subtly similar to the current event timeout. It would<br clear="none">> > need a new option, e.g {state_timeout,T,Msg}.<br clear="none">> > <br clear="none">> > The {state_timeout,_,_} semantics would be just a special case of using<br clear="none">> > erlang:start_timer/4,3, keep your timer ref in the server state and cancel<br clear="none">> > it when needed, since in the general case you might want to cancel the<br clear="none">> > timer at some other state change or maybe not a state change but an event.<br clear="none">> > <br clear="none">> > So the question is if a {state_timeout,_,_} feature that auto cancels the<br clear="none">> > timer at the first state change is so useful that it is worthy of being<br clear="none">> > implemented? It is not _that_ much code that is needed to store<br clear="none">> > a timer ref and cancel the timer started with erlang:start_timer/4,3,<br clear="none">> > and it is more flexible.<br clear="none">> > <br clear="none">> > I implemented the {timeout,_,_} feature just so make it easy to port from<br clear="none">> > gen_fsm. Otherwise I thought that using explicit timers was easy enough.<br clear="none">> > <br clear="none"><br clear="none">-- <br clear="none"><br clear="none">/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br clear="none">_______________________________________________<br clear="none">erlang-questions mailing list<br clear="none"><a shape="rect" ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br clear="none"><a shape="rect" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></div><br><br></div> </div> </div> </div></div></body></html>