On the windows-port branch we simply conformed with what we thought the other platforms were doing. From what I can tell, I think GetSystemTimeAsFileTime on Windows is similar to clock_gettime with CLOCK_REALTIME as a parameter. We could probably do better by using QueryInterruptTime to be more like the CLOCK_MONOTONIC version, which is presumably less fragile.
I?m not familiar with a cross-platform time function that won?t be lacking in some way. Therefore, I think Windows will need its own block of timer code. Whether that code is wrapped with #ifdefs or in different files doesn?t matter to me, as long as we are not creating too much repetition in the codebase. David From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Gregg Reynolds Sent: Wednesday, June 15, 2016 5:32 PM To: Macieira, Thiago <thiago.macieira at intel.com> Cc: iotivity-dev <iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Timer Portability On Wed, Jun 15, 2016 at 12:42 PM, Thiago Macieira <thiago.macieira at intel.com<mailto: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/20160616/262a7e1a/attachment.html>
