[erlang-questions] Timers for hibernated processes

Max Bourinov bourinov@REDACTED
Thu Nov 24 06:52:50 CET 2011


This is not a conclusion, this is assumption.

Please try it out on your system and tell us about results?

Best regards,
Max




On Thu, Nov 24, 2011 at 5:46 AM, Barco You <barcojie@REDACTED> wrote:

> 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/a4b8587c/attachment.htm>


More information about the erlang-questions mailing list