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)intel.com> 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)gmail.com] Sent: Friday, April 8, 2016 4:38 AM To: devel(a)lists.zephyrproject.org Subject: [devel] RFC: Timer/Timeout API
Hi,
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:
net/ip/net_core.c:666: 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; } ... fiber_sleep(next_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?
