gen_fsm:send_after | start_timer

[Sean Hinde]

> Hi,
> I do not have a decent work environment to do any tests 
> right, but I believe
> that an attempt at cleaning up the timer module has been 
> made. The design rule
> in the AXD is from 1996, and a lot has changed since then. I 
> do not think the
> ban is in the updated design rules.
> 
> I notice that the timers are still inserted in lists using 
> insertion sort, so if
> timing is still a problem (How many timers will you have 
> running at any one
> time?), I would personally rewrite the timer module instead 
> of complicating the
> FSMs.

Yes, I thought some more since your last post and also decided fixing timer
would be more in line with the general ethos.. Yet I just spent the last
couple of hours getting my head around a particularly complex gen_fsm and
have grown to really like my addition.. I had a big itch to scratch in doing
that change and it has helped enormously.

On a more definite note timer:apply_after/4 loses the nice property of
erlang:start_timer/3 that the timer ref is included in the sent message.
This is impossible using timer:apply_after because you don't know the ref
until after the message is sent(!)

Also my solution is much cleaner for users of gen_fsm because it does not
require a whole raft of exported functions just to wrap the timers.

And my solution is just about as efficient as timers get with only 1 message
sent - the actual timer.

So, I think that timer should be fixed,

And I will keep my change, rely on it making my head hurt less, enjoy the
fact that it makes my code more maintainable (IMHO), and hope others like it
:)

Cheers,

Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.