[erlang-questions] Sending message at a specific and accurate time
Mon Feb 22 17:58:02 CET 2016
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
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
Midi is essentially "play this note" at time <t>, which is not that
"send this message" at time <t> - and core audio supports this at a very low OS
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
> 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.
> Rickard Green, Erlang/OTP, Ericsson AB
More information about the erlang-questions