<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Nov 20, 2016 at 10:13 PM nato <<a href="mailto:nbartley@umail.iu.edu">nbartley@umail.iu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On a whim, I started an erlang shell, counted the processes (some 25),<br class="gmail_msg">
then called `erlang:send_after/3` -- I was surprised to see that the<br class="gmail_msg">
count of processes never went up. Do these timer routines not spawn a<br class="gmail_msg">
new process!? Seems like a perfect candidate for such. 'Would love<br class="gmail_msg">
some hand-holding on how this all works before I stare at the source.<br class="gmail_msg"></blockquote><div><br></div><div>In a non-optimizing implementation of Erlang, you might indeed implement send-after as a process spawn. Something akin to:<br><br></div><div>send_after(Wait, Target, Msg) -><br></div><div>    spawn(fun() -><br></div><div>        receive<br></div><div>        after Wait -><br></div><div>          Target ! Msg<br></div><div>        end<br></div><div>    end).<br><br></div><div>In practice you would need to extend the receive clause so it can handle a cancel-message in the mailbox and return the right value, but this is somewhat trivial (though it is gritty).<br><br></div><div>In an optimizing Erlang-implemention, you want timers to be internal in the system. You want precise wakeup of timers when they trigger and you want them to have little memory overhead. This guarantees the soft real-time properties and makes timers fast. So timers are implemented directly in the runtime, separate from processes.<br><br></div><div>The "trick" of having a nice "consistent" and "simple" theory which is then torn down in an industrial practical setting is something you see pretty often. On one hand, you can understand the system based on its simple model. And you can verify the correctness of that model against the practical and fast variant of the system. In fact, there is a direct path from this observation to monads and their use in proofs.<br><br></div><div>Another for-efficiency part of the Erlang system are ETS tables, which are implemented not as processes but as highly optimized concurrently accessible memory tables. The reason is that Key-Value lookups in mnesia had the requirement of microsecond latency, and this is not achievable in a process if the system is under heavy load and that processes is at the end of the run-queue.<br> <br></div></div></div>