Re: RFC: Timer/Timeout API

Dmitriy Korovkin

On Fri, 8 Apr 2016, Luiz Augusto von Dentz wrote:


For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.
I am not quite sure I understand the problem. Kernel keeps the track of
nanokernel timers and timeouts. If needed, each fiber can wait on a
timer (one fiber per timer). Not sure, what is the need for a separate
fiber that runs through the timers.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.
Depends on what is needed. If this is a global change (apility for
multiple fibers to wait on one timer, for instance), this should be

- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?
As the kernel keeps track of the timers, there may be something else is


Join to automatically receive all group messages.