[erlang-questions] Minimum time for timer:sleep()?

[David Hopwood]

Per Hedeland wrote:
> "Bob Ippolito" <bob@REDACTED> wrote:
> 
[...]
>>I have no idea what the Erlang VM does but I'd guess that this 10 msec
>>granularity comes from the fact that multiplexing syscalls like
>>select/poll or kqueue (at least on OS X) are about that accurate when
>>you use them to sleep.
> 
> Yes, it's nothing Erlang-specific - pretty fundamental actually:
> Timeouts can only happen on a system clock interrupt, and they obviously
> happen with the frequency of your system clock, which is traditionally
> 100 Hz on Unix.

Not obviously; there is no reason other than implementation simplicity why
interrupts need to be periodic. It would be perfectly feasible to set the
timer to interrupt precisely on the next timeout requested by any application,
as some real-time operating systems do. There is even an actively maintained
Linux kernel patch to do that:

  <http://www.tglx.de/hrtimers.html>
  <http://www.tglx.de/projects/hrtimers/ols2006-hrtimers.pdf>

but whether this would work from Erlang depends on which API the Erlang
emulator is using for timeouts, and in any case the OP was using a Mac
(so probably not Linux).

Note that even with a high-res timer API on a real-time OS, the latency
of timeout callbacks is unavoidably increased when multiple applications
request a timeout at about the same time.

> None of that helps, nanosleep despite its name is still limited by the
> system clock frequency - it's just that when POSIX decided to specify
> something that could let you sleep with better granularity than 1
> second, they wanted to be future-proof.:-)

Or to allow the above technique for precise timeouts.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>