On quarta-feira, 15 de junho de 2016 19:31:31 PDT Gregg Reynolds wrote:
> On Wed, Jun 15, 2016 at 12:42 PM, Thiago Macieira <thiago.macieira at
> intel.com
> > Yes, use mach_absolute_time.
>
> Wheee! This is fun! According to Timers, Clocks, and Cocoa
> <http://devetc.org/code/2014/01/21/timers-clocks-and-cocoa.html>, "the
> monotonic clock [i.e. the one used by mach_absolute_time()] stops when the
> CPU is powered down". It recommends "boot time" reported by "uptime",
> which is a command. Well I guess if its monotonic that's good, but if it
> stops counting when it goes to sleep that's not so good.
It's good enough. The worst case scenario is that a 30-second timer takes 30
seconds after resuming to fire, even if you let the computer sleep for 2 hours.
And that's a good thing, because you avoid the "thundering herd" problem of
every timer expiring on every application right as you resume from sleep.
> What's going to happen when somebody tries to port Iotivity to e.g. the
> ESP8266, or the Adafruit Trinket, or etc.? (Which I would love to do, but
> don't have the time.) How much functionality (in addition to timer stuff)
> is HOST_OS-dependent? Two obvious candidates: filesystem and memory ops.
> Should we start identifying that kinda stuff and wrapping it in
> conditionals?
A lot of it is OS-dependent and the Windows port team has already done a great
job in identifying those bits and is in the process of creating a better
abstraction layer. That's why I asked you to work with them whenever possible.
> Windows: the proposed port uses GetSystemTimeAsFileTime. Is that the Right
> Thing? I have no idea, but I think it would be useful to have it discussed
> for the record.
GetSystemTimeXxx is wall-clock time. To get the monotonic clock, one needs
either GetTickCount64 or QueryPerformanceTimer. std::steady_clock uses the
latter, as the precision of the former is too coarse for our uses (15-16 ms on
my machine).
> So we have Un*x stuff, and Windows stuff. I'm not sure how to categorize
> Android and generic Java. And we have some Arduino stuff. You mentioned
> somewhere "don't worry about the RTOS stuff" (in so many words); I'm not so
> sure that's a good idea. I think it would be good to have at least one
> RTOS under active development if only to discover RTOS-related hairballs.
> Zephyr would be my candidate ('m planning to look at a Zephyr port but I'm
> pretty sure it would be too much at the moment.)
We do have RTOS plans, but not in the main IoTivity source code. There's a
separate source code for small and real-time OSes.
Zephyr port already exists.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
