<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_779226" dir="ltr"><span id="yui_3_16_0_ym19_1_1474984041665_779328">The state_timeout that was added makes more sense to me IMO. And what Fred said about uses for the current timeout being more limited are valid.<br><br><br><br></span></div><div id="yui_3_16_0_ym19_1_1474984041665_779226" dir="ltr">I think that if there is support for the way the current timeout is, that times out regardless of the state you are currently in, what is the problem with having one vs multiple of them?<br><br>Is it really that much of an annoying feature to add. Where the cost of maintenance of the code will be greater then the benefit? <br>I even mentioned I would put in the pull request for it if we can agree it would serve some use.</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 Wednesday, October 5, 2016 9:45 AM, Raimo Niskanen <raimo+erlang-questions@erix.ericsson.se> wrote:<br></font></div> <br><br> <div class="y_msg_container">On Tue, Oct 04, 2016 at 10:52:38PM -0500, Fred Hebert wrote:<br clear="none">> On 10/04, Vans S wrote:<br clear="none">> :<br clear="none">> >I did not consider this. This is truly problematic BUT would not the <br clear="none">> >current way timeout works run into this same problem? So this should <br clear="none">> >not affect allowing multiple timeouts vs a single timeout.<br clear="none">> <br clear="none">> Right now what you can do if you manage your own timers is to cancel the <br clear="none">> old ones or ignore them (you've got their refs so it's easy) and you can <br clear="none">> set new ones right away. You can't do that however if you rely on the <br clear="none">> return tuple of a state transition to do it, since that transition <br clear="none">> cannot happen from a code_change callback.<br clear="none"><br clear="none">To some extent this cat is already out of the box thanks to the gen_fsm<br clear="none">timeout that got inherited to gen_statem. If such a timer is running and<br clear="none">there is a code change on the server, it may expire "earlier" than you<br clear="none">would like or rather suddenly you might have wanted this particular timeout<br clear="none">to be longer.<br clear="none"><br clear="none">If this is a real problem you can set a flag in your Data to note that<br clear="none">there has been a code change, and then act differently when the timeout<br clear="none">comes, or change states to one that is aware of the possibility of an early<br clear="none">timeout.<br clear="none"><br clear="none">I wonder how this affects my state_timeout proposal...<br clear="none">It has got the same corner case, and the same workarounds apply.<br clear="none"><br clear="none">The same would apply to named_timeout, with the same workarounds,<br clear="none">but the more timers you do not control, the messier to work around,<br clear="none">I guess...<br clear="none"><br clear="none">> <br clear="none">> >Learning from that, I rather this be inside gen_statem. If its not, I <br clear="none">> >would have no problem to write my own little timer library for <br clear="none">> >cancel_timer+purging mailbox. <br clear="none">> ><br clear="none">> <br clear="none">> Usually the pattern I use is to write a short 'reset_<whatever>_timer' <br clear="none">> function that returns its ref, and then I can track the ref in my state.<br clear="none"><br clear="none">It may be a bit tricky to get it right, but it is educational.<br clear="none"><br clear="none">The problem in writing a library for this is that there are some options<br clear="none">on both how to start a timer and how to cancel it, so a library would<br clear="none">either not get it right for everybody or would have to take very many<br clear="none">options to be right for everybody.<br clear="none"><br clear="none">So this may be a good candidate for a do-it-as-you-want-it library module.<br clear="none"><br clear="none">/ Raimo<div class="yqt9702175841" id="yqtfd86621"><br clear="none"><br clear="none"><br clear="none"><br clear="none">> <br clear="none">> I always found this fairly convenient to deal with things, and for <br clear="none">> example, I mostly don't clean up timers very hard. I.e. you can make use <br clear="none">> of the newer cancel_timer options for async returns with or without <br clear="none">> info, and by matching on specific refs, I can just ignore timers that <br clear="none">> are for events I know are no longer up for consideration and let them <br clear="none">> disappear, and automatically can ignore a bunch of potential race <br clear="none">> conditions (i.e. no mailbox cleanup, just ignore messages coming in)<br clear="none">> <br clear="none">> This is also neat to avoid whatever blocking or synchronization that <br clear="none">> could take place on timer management, but in some cases you may still <br clear="none">> want to do that.<br clear="none">> <br clear="none">> <br clear="none">> >Since you are only in ONE state at a time, you automatically know if <br clear="none">> >the timeout happened, it MUST correspond to the current state we are <br clear="none">> >in. <br clear="none">> ><br clear="none">> <br clear="none">> Does it? Couldn't the timeout event have been postponed, and therefore <br clear="none">> come from a prior state change? I believe so. There's no relationship <br clear="none">> between an event being handled in a state and that event having been <br clear="none">> sent in that state.<br clear="none">> <br clear="none">> >Another option is to remove the timeout then. It just seems out of place to me. <br clear="none">> ><br clear="none">> <br clear="none">> At the two extremes are the positions that all timeout management is <br clear="none">> manual, and that gen_statem is to replace full-on control of timeouts <br clear="none">> people can do manually (with all the cancellation options and whatnot).<br clear="none">> <br clear="none">> Those are the two extremes, and the current thing is where on the <br clear="none">> gradient does the timeout implementation currently lie. So far it <br clear="none">> appears to be a fairly minimal convenience factor. I'm just wondering if <br clear="none">> it's worth pushing it further on the gradient of "emulating all the <br clear="none">> flexibility of manual control."<br clear="none">> <br clear="none">> >What is the use case of a single timeout with a UNIQUE EventContent?<br clear="none">> ><br clear="none">> <br clear="none">> The current semantics are specific about one thing:<br clear="none">> <br clear="none">> Generates an event of event_type() timeout after this time (in <br clear="none">> milliseconds) unless another event arrives in which case this <br clear="none">> time-out is cancelled. Notice that a retried or inserted event <br clear="none">> counts like a new in this respect.<br clear="none">> <br clear="none">> These timeouts are mostly used for one thing in my experience: tracking <br clear="none">> inactivity of the state machine. gen_servers and gen_fsms have the same <br clear="none">> one. The only pragmatic use case I've made of them were to give myself a <br clear="none">> delay of N milliseconds before which it would be reasonable to send the <br clear="none">> process in hibernation, GCing and compacting its memory at once, since <br clear="none">> it had not received a message in that time otherwise.<br clear="none">> <br clear="none">> All other timeouts I tend to manage by hand because I do not want them <br clear="none">> to be interruptible by the arrival of other messages in the mailbox of <br clear="none">> the process.<br clear="none">> <br clear="none">> This is a very, very important detail! Those semantics are also a lot <br clear="none">> trickier to handle by yourself (you'd need to put them in every clause) <br clear="none">> than most other timers you could imagine using. This makes them a fairly <br clear="none">> good idea to include in the OTP behaviours themselves, as opposed to <br clear="none">> most other timer usages, IMO.<br clear="none">> <br clear="none">> Regards,<br clear="none">> Fred.</div><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><br><br></div> </div> </div> </div></div></body></html>