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.

> 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.

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clock_gettime.c
Type: text/x-csrc
Size: 904 bytes
Desc: not available
URL: 
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160615/767e9153/attachment.bin>

Reply via email to