[erlang-questions] erlang:send_after/3 questions

Mahesh Paolini-Subramanya <>
Sat Sep 22 02:13:57 CEST 2012


The timer module is basically a gen_server that is using timeouts to invoke a timer and an ordered_set ETS to store the timers
The ordered_set is probably the cause of the memory issues you are referring to, and the gen_server/timeout implementation is, well, not exactly the most scalable way to do this...

Cheers
Mahesh Paolini-Subramanya
That Tall Bald Indian Guy...
Blog   |   Twitter   |   Google+

On Sep 21, 2012, at 7:25 PM, Michael Truog wrote:

> On 09/21/2012 03:15 PM,  wrote:
>>> 3. Is spawning a lot of send_after's or timers a dangerous idea? In case of
>>> using timer module, we'll just lose some started timers due to port
>>> restart. But something tells me that crash of erlang internal timers is a
>>> somewhat more dangerous thing that might even crash the VM.
>> Not sure I understand you here.
>> 
>> These timers are a facility built directly into ERTS. If there were a
>> bug somewhere in the implementation, that could be as horribly nasty
>> as any other bug in ERTS. Other than that, they are dead pieces of
>> data interpreted in some conventional way by a bunch of C code, so
>> as such they can't really "crash" in any obvious meaning of the
>> word.
> 
> I remember reading about problems using the timer module with a large number of timers because of excessive memory consumption, such that erlang:send_after/3 or erlang:start_timer/3 is generally the preferred approach.  I don't have a link to the mailing list message(s) for instances of that problem, but I assume it is still an issue today, because of extra storage used by the timer module.
> 
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120921/9aecfe23/attachment.html>


More information about the erlang-questions mailing list