more questions! We encountered some problems using vtimer. For once, setting multiple short timers consecutively leads to a segfault. We tired this with the timer_msg test reducing the intervals to around 150ms.
A second problem showed up when setting multiple timers at once, e.g., from different threads. After a short time the "timer is already due” warning from schedule timer in hwtimer_cpu.c flashed and soon after the timers simply stopped.
So, I am not sure if these problems originate in our own implementation or the native port. In order to test the short timers, we executed the same program on the iot-lab_M3 board, where it worked even with much shorter timers.
looks better. Some of the tests that did not work before, work fine now, e.g. using multiple timers.
Setting a consecutive timer around 1 milliseconds still seem to end up in a freeze.
Most often with the error: "schedule_timer(): timer is already due (3), mitigating.”.
my setup uses CAF (C++) together with RIOT on a 64 bit Linux (Debian).
I created a branch in my RIOT fork which includes all the code to make the example work [1]. You can find it under "test/cpp_timer/“. It depends on an implementation for thread, mutex and condition_variable that is mostly STL compliant and is based on RIOT. Not STL compliant is, e.g., the chrono implementation used in the test … (it is atm. only sufficient to make CAF work).
I added your fixes to the branch. Btw, there are some errors on OS X [2].