gen_fsm:send_after | start_timer

[Sean Hinde]

> >apply_after(T, M, F, A) ->
> >	erlang:start_timer(T, timer, {apply, M, F, A}).
> >
> >%% Permanent loop registered as {local, timer}:
> >
> >loop() ->
> >    receive
> >        {timeout, Ref, {apply, M, F, A}} ->
> >            spawn_link(?MODULE, do, [M, F, A, self()]),
> >            loop().
> >
> >do(M, F, A, Pid) ->
> >	apply(M, F, A).
> >	unlink(Pid).
> 
> You will reduce the overhead, but add latency since all the
> timer functions must be serialized. This will force the
> requirement on the user of the timer to keep the function very
> short, which is sometimes inconvenient.

No, they are still spawned in their own process

> Also, I'd put a catch around the apply. ;)

Good point!

> Yes, but Erlang handles lots of extra processes exceedingly well.
> I wouldn't worry about the performance aspect, but memory could
> sometimes be a factor.

Hmm, OK.

I still like extending gen_fsm with timers. Timers are pretty key to most
protocol FSMs and this makes them extremely neat and safe for protocol
implementers, as well as giving maximum efficiency.

The attached new version of my patch adds a gen_fsm:cancel_timer which is
guaranteed to remove the timer even if already in the message queue (for
both send_after and start_timer, which is not possible with the normal
erlang:send_after/3). It also tidies up the sys:trace wording.

- 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.


  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen_fsm_timer2.diff
Type: application/octet-stream
Size: 3436 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20010711/a98345a6/attachment.obj>