[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.

UUgh -- that's horrible - seems daft setting a microsecond timer
if it refuses to obey - (

There might be a crazy work around - on the mac core audio
can send midi events at very precise times - so if you subscribe to these
 you'll get a callback up at a very precise time - so you could use the midi
scheduler to schedule future events.

(Actually I ran into this problem when generating audio events, so it's not
surprising)

Midi is essentially "play this note" at time <t>, which is not that
different from
"send this message" at time <t> - and core audio supports this at a very low OS
level.

The audio timers are designed to take priority over other timers and are
be very accurate ...

A quick google search turned up several posts that pursued this idea

/Joe

> 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.
>
> Regards,
> Rickard
> --
> Rickard Green, Erlang/OTP, Ericsson AB