[erlang-questions] Timers for hibernated processes

[Barco You]

So, the conclusion is that receive-after clause is better than
erlang:start_timer() for sending tick messages?


Barco

On Thu, Nov 24, 2011 at 3:50 AM, Max Bourinov <bourinov@REDACTED> wrote:

> Hi All!
> I have very similar problem: 500K gen_server processes that should get
> tick message every X seconds.
>
> I have tried timers module, but since it uses ets I decided to do
> something else (my processes lives in gproc which also uses ets - this why
> I decided to reduce double ets penalty).
>
> What I did is I created something like this:
>
> -spec start_tik_timer(State :: #state{}) -> #state{}.
>
> start_tik_timer(State) ->
>
> 	case State#state.tref of % Here I store ref to the timer process
>
> 		% No timer, so we run one
>
> 		undef ->
>
> 			Self = self(),
>
> 			Fun = fun(ThisFun) ->
>
> 					Self ! {tik},
>
> 					receive after ?TIK_TIME -> ok end, % This is my tick time
>
> 					ThisFun(ThisFun)
>
> 				  end,
>
> 			Pid = spawn(fun() -> Fun(Fun) end),
>
> 			State#state{tref = Pid};
>
> 		% There is one - do nothing
>
> 		_TRef ->
>
> 			State
>
> 	end.
>
>
>
>
> And I catch ticks like this:
>
> handle_info({tik}, State) ->
>  % ..... you code here ...
>  {noreply, State};
>
> This approach was suggested by Erlang gurus in another thread.
>
> If you want, please try it! Would be great to know your results!
>
> Best regards,
> Max
>
>
>
>
> On Wed, Nov 23, 2011 at 7:30 AM, Barco You <barcojie@REDACTED> wrote:
>
>> I wonder what the difference is between using erlang:start_timer(Timeout,
>> Pid, Msg) and directly using the receive-after clause as below:
>>
>> receive
>>        _Event -> ok
>> after
>>         Timeout -> Pid ! Msg
>> end
>>
>>
>>
>> On Wed, Nov 23, 2011 at 7:20 AM, Scott Lystig Fritchie <
>> fritchie@REDACTED> wrote:
>>
>>> Jesper Louis Andersen <jesper.louis.andersen@REDACTED>
>>> wrote:
>>>
>>> jla> In *principle* this kind of structure should be extremely
>>> jla> scalable. I would try reconstructing the problem without any kind
>>> jla> of other subsystem (TCP, Cowboy, ...) first, so you have a smaller
>>> jla> failing test case. Then you can probably instrument Erlang/OTP by
>>> jla> inspecting the Timer wheel. This will probably tell us a lot more
>>> jla> about the limitations of the timer wheel structure in this case.
>>>
>>> Sounds like an excellent use of DTrace, hint hint.....
>>>
>>> The hints aren't just for Jesper and Zvi but anyone else who's intersted
>>> in measuring the behavior of stuff inside the Erlang VM.  This stuff is
>>> working its way into (we hope!) R15B right now.  To read more about it,
>>> see:
>>>
>>>
>>> http://www.snookles.com/slf-blog/2011/11/19/dtrace-and-erlang-a-status-report/
>>>
>>> http://www.snookles.com/slf-blog/2011/11/19/systemtap-and-erlang-a-tutorial/
>>>
>>> -Scott
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111124/713746e7/attachment.htm>