Re: RFC: Timer/Timeout API

Luiz Augusto von Dentz

Hi Marcel,

Do you have anything to add? Or is this something that came out while
discussing with Daniel due to my MSR?

On Fri, Apr 8, 2016 at 8:48 PM, Kalowsky, Daniel
<daniel.kalowsky(a)> wrote:
+ Marcel, as he mentioned some changes to both areas (I think) at OpenIoT.

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz(a)]
Sent: Friday, April 8, 2016 4:38 AM
To: devel(a)
Subject: [devel] RFC: Timer/Timeout API


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.

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.
- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?
- Where would be the best location in the source tree?

Luiz Augusto von Dentz

Luiz Augusto von Dentz

Join to automatically receive all group messages.