On Wed, Jun 15, 2016 at 12:42 PM, Thiago Macieira <thiago.macieira at intel.com > wrote:
> On quarta-feira, 15 de junho de 2016 09:23:54 PDT Gregg Reynolds wrote: > > Reviewers of https://gerrit.iotivity.org/gerrit/#/c/8603/ rightly > pointed > > out that it is not maximally portable. FWIW I do not think patches that > > make Iotivity run on a new platform without breaking existing platforms > > should be asked to also solve problems on all possible platforms, but > > that's a separate issue. The purpose of this message is to sketch a > > possible way of dealing with timers in a portable way. > > Hi Gregg > > You're right: you can't be asked to test a platform that isn't supported > yet > and you may not have access to. However, if someone makes a suggestion to > "do > A instead of B" because then other platforms will work, you should at least > attempt that. > Please don't assume I did not. > > > Code that runs on Darwin uses #ifdef on _POSIX_TIMERS to select > > "clock_gettime" else "gettimeofday" ; Darwin has the latter not the > former. > > In patch 8603 (link above) I tried to make the code in the offending > files > > follow the working code in the other files. > > And I asked you to instead #ifdef CLOCK_REALTIME, since that will work on > OpenBSD too, which doesn't define _POSIX_TIMERS but has clock_gettime. Please read entire msg before responding. ;) I'm a little embarrassed to report that Ossama suggested we look at using OICGetCurrentTime() in resource/c_common/oic_time/. Which I knew about but for some reason it never occurred to me. I don't know if that will Solve All Problems but if it's good enough that would be great. -Gregg > > > The reviewers pointed out that: > > > > * The Windows port adopts an autoconf-like approach using e.g. "#if > > defined(HAVE_GETSYSTEMTIMEASFILETIME)" to select Windows code. > > Which is nice, but not necessary if you have a macro that can be tested and > strictly defines whether the function you're looking for exists. That > would be > CLOCK_REALTIME. > > > * There are issues with _POSIX_TIMERS, CLOCK_MONOTONIC, etc. I haven't > been > > able to find an unambiguous definition of exactly what _POSIX_TIMERS > > implies. See POSIX Conformance > > <http://pubs.opengroup.org/onlinepubs/007904875/basedefs/xbd_chap02.html > >, > > Feature > > Groups <http://pubs.opengroup.org/onlinepubs/007908775/xsh/feature.html > >etc. > > Example: OpenBSD only partially supports the posix "timer option" so it > > does not define _POSIX_TIMERS but it does have clock_gettime, > > CLOCK_MONOTONIC, and CLOCK_REALTIME (manpage > > <http://man.openbsd.org/clock_gettime.2>). > > _POSIX_TIMERS implies a bunch of functions, not just clock_gettime. That's > why > OpenBSD doesn't #define it: they did not implement one of the pthread > functions > that would be required in order to define _POSIX_TIMERS. > > As for the monotonic clock, it's almost always a good idea to use it, to > avoid > clock jumps due to the system real time being updated. It's just a pity > that > Apple was lazy and did not implement it in their libc, since they have > everything they need to do it. LLVM's libc++, like Qt, works around the > issue > by calling a Mach function. > > Here's the implementation is attached (I've just written it; note, it might > not be totally thread-safe). > > > * There are lots of other OSes, e.g. the BSDs (Free/Net/etc.) and many > > RTOSes, all of which may do things differently. > > Don't worry about the RTOSes. For the BSDs, best effort is enough. Like I > said, I'm not asking you to test on them, but I did give you the solution. > > > An alternative is to split the code into platform-specific c files, and > > select the file to use at build time based on feature detection. Taking > > pmutililty.c as an example, we might have a "timer" subdir within > > provisioning/src, and then for e.g. Darwin we would have timer/darwin.c > > containing something like: > > That would be best, indeed. > > > ... > > #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. > > But this function (PMTimeout) should not exist at all. Anything using it is > probably a flawed design. > > > Instead of timer/linux.c, we would have timer/posix.c, which would not be > > linux-specific (would it work for Tizen?). So to get started we would > have: > > > > resource/csdk/security/provisioning/src/timer > > - darwin.c > > - posix.c > > - win32.c > > > > Comments? > > Yes, please! > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160615/f6953753/attachment.html>
