On Wed, Jun 15, 2016 at 12:42 PM, Thiago Macieira <thiago.macieira at intel.com
> wrote:
...
> ...
> > #include <sys/time.h>
> > ...
> > OCStackResult PMTimeout(unsigned short waittime, bool
> waitForStackResponse)
> > {
> > OCStackResult res = OC_STACK_OK;
> > static const struct timeval zeroTime = { .tv_sec = 0, .tv_usec = 0 };
> > struct timeval startTime = { .tv_sec = 0, .tv_usec = 0 };
> > struct timeval currTime = { .tv_sec = 0, .tv_usec = 0 };
> > clock_res = gettimeofday(&startTime, NULL); //FIXME: use
> > mach_absolute_time?
>
> 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.
This at least has the virtue of making it clear (I think) that timer code,
if it is to be conditionally compiled, must be determined by TARGET_OS, not
HOST_OS.
Obvious example: my host os is Darwin, but I'm making an Iotivity widget
for iOS. The timing functions on Darwin/OSX are irrelevant.
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?
More info for the record:
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.
See Unix Time and Windows Time
<https://blogs.msdn.microsoft.com/mikekelly/2009/01/17/unix-time-and-windows-time/>
, GetTickCount
<https://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx>,
QueryPerformanceCounter
<https://msdn.microsoft.com/en-us/library/ms644904(VS.85).aspx>, Acquiring
high-resolution timestamps
<https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx>,
etc.
Do a web search on e.g. Windows Monotonic Clock.
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.)
Havin' a blast,
Gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160615/17eaec28/attachment.html>
