[erlang-questions] Using sigwait in linked driver causes erl_ddll:load to return {error, {open_error, -10}}

[Serge Aleynikov]

It is true that Erlang emulator doesn't have a good way of dealing with 
sub-millisecond timers.  I think Ulf Wigger touched on this topic in the 
list some time back.

If you happen to be using a linux kernel 2.6.22 or later you can use a 
more fancy timer mechanism via timerfd syscall.  This can create a timer 
file descriptor that you can register with the emulator via 
driver_select call.  This timer will have microsecond precision.

Serge

Rob Elsner wrote:
> Serge,
> 
>> Could you share with us how high resolution timers are related to sigwait?
>>
> 
> sigwait is then used to wait for that signal, at which point I would
> message the Erlang process.
> 
> Is there a better way?  I am not concerned about accurate timing of
> events, what I truly need is relatively accurate signaling to do work.
>  In this case I am looking for reliable timers to generate UDP packets
> in the microsecond range.
> 
>> If your mere use of linked-in driver is to get access to high-res timers,
>> the overhead of calling a function through a linked-in driver (that can take
>> 5-10us) will defeat the purpose of high-res timers (that give nanosec
>> resolution).  Though up until FFI is embedded in the distribution this is
>> the "fastest" existing interface.
> 
> When we did some testing with the Erlang built in timer server, the
> best we could mange reliably was 1 millisecond.  If you look at the
> rt-tests
> http://www.kernel.org/pub/linux/kernel/people/tglx/rt-tests/
> 
> the cyclictest uses timer_create to generate a sigevent at a specified
> interval.  On my hardware this provides a practical 10us timer
> interval.  I are looking for ~100us interval timer resolution.
> 
> Thanks,
> Rob
>