[erlang-questions] Sending message at a specific and accurate time

[Joe Armstrong]

On Mon, Feb 22, 2016 at 4:55 PM, Rickard Green <rickard@REDACTED> wrote:
>> I can only conclude that send_after(Time, Pid, Msg) is deeply broken on the
>> mac - if inter-processing scheduling and messaging had 6 millisecond
>> delays Erlang would be unusable.
>>
>
> When schedulers run out of work they eventually need to sleep. A
> timeout is set up in order to service next timeout. On macosx we will
> sleep in select(). The timeout is set on microsecond level, but on
> macosx the thread is often woken milliseconds after the time we
> requested. When the thread wakeup is delayed like this, timers handled
> by the thread will also be delayed. I verified the delayed timeout in
> select() using a simple c-program, and the figures corresponds to what
> can be seen in your send_after() test. That is, it is not the timer
> implementation in the vm that delays the timers.
>
>> I guess I could do a send_after 10ms before I want and then do a busy wait
>> but this would be crazy.
>>
>
> If the primitive used for waiting has this kind of delay, a busy wait
> is more or less what is left. The vm could of course perform this busy
> wait for you, but my guess is that this busy wait wouldn't be received
> well by the users. It is however an option.

You'd need two primitives

    send_after  (as today) and send_after_precise(Effort, Time, ...)

where Effort is high, low, ... (or something)

   Actually I think this is a key primitive in Erlang - far more
important than maps
and module names - the "essence" of Erlang has to do with messaging -
this is where Erlang should (and does) excel - the rest (maps, etc.)
is just syntax.

Sending a message at a precise time is an underlying mechanism upon
which a large number of things can be built.

Why is Erlang great? - because you can have thousands of parallel processes
and send and receive message quickly. The Zen of erlang involves fast
process spawning, fast message sending and receiving and control over
time.

Personally I would put a lot of effort into getting this right -

Remember it's all about messaging, all the rest is syntax

Cheers

/Joe




>
> Regards,
> Rickard
> --
> Rickard Green, Erlang/OTP, Ericsson AB