[core]:fix pthread_condattr_setclock on lower versions of Android

[lilinxiong]

No description provided.

[cl-ment]

Thank you, lilinxiong, for reopening this pull request. It is related to #3138, which I mistakenly closed. My apologies again.

[ethouris]

Ok, very good, just please @lilinxiong do the fixes:

1. Remove ANDROID from checks. The existence of pthread_condattr_setclock is ALWAYS required, if you set monotonic clock, regardless of the system and regardless of the fact that only older version of Android have problem with it. The informative message that the checks is done is also unnecessary.
2. In Travis (.travis.yml) there is a build definition which will be done also on systems that require also posix threads and monotonic clock. Therefore in the cmake command that is called there the -DENABLE_MONOTONIC_CLOCK=ON must be added, otherwise some builds will fail.

[lilinxiong]

Ok, very good, just please @lilinxiong do the fixes:

1. Remove ANDROID from checks. The existence of pthread_condattr_setclock is ALWAYS required, if you set monotonic clock, regardless of the system and regardless of the fact that only older version of Android have problem with it. The informative message that the checks is done is also unnecessary.
2. In Travis (.travis.yml) there is a build definition which will be done also on systems that require also posix threads and monotonic clock. Therefore in the cmake command that is called there the -DENABLE_MONOTONIC_CLOCK=ON must be added, otherwise some builds will fail.

I feel that it’s clearer to look at the CMake logs; words aren’t very good at expressing this. Now I’ve added a message in CMake, which is to print the current system name.

Then I will remove the judgment for the platform, which means I will only check if ENABLE_MONOTONIC_CLOCK is set to ON. After that, I will re-run the configuration on Darwin, and I will get the following results.

That is to say, this is not in line with our expectations, and in actual usage on Darwin, we don’t need to enable ENABLE_MONOTONIC_CLOCK at all. However, only POSIX is true:

Then, when POSIX is true, it will proceed to test_requires_clock_gettime(ENABLE_MONOTONIC_CLOCK_DEFAULT MONOTONIC_CLOCK_LINKLIB). Here, ENABLE_MONOTONIC_CLOCK_DEFAULT will be true, and ultimately ENABLE_MONOTONIC_CLOCK will be true.

So, we actually can’t just determine if ENABLE_MONOTONIC_CLOCK is true. At least that’s how it seems for now. We either need to adjust the condition for setting ENABLE_MONOTONIC_CLOCK_DEFAULT to true. That is, it will only be enabled when ENABLE_MONOTONIC_CLOCK is needed.

[ethouris]

There's quite a mess with this definition here, but as long as I look at it, ANDROID is included in POSIX, so this should be checked anyway.

In 1.6.0 we'll simplify this, but CMakeLists.txt will be reworked upside down and won't be mergeable with whatever next is added to 1.5.5 (I'll have to add changes through distillation). Conditions will be also changed, some deprecated configurations will be no longer supported. I also added these changes you made here a little differently. Still, this fix better go to 1.5.5 and in the form that doesn't change fundamentally the configuration rules (which I did in the development for 1.6.0).

Therefore all we need is that if monotonic clock is requested and available, this *_setclock function must be available, otherwise it should make a fatal error. And all we need to make sure is that it detects this situation correctly on old Android version.

[lilinxiong]

Ok, very good, just please @lilinxiong do the fixes:

1. Remove ANDROID from checks. The existence of pthread_condattr_setclock is ALWAYS required, if you set monotonic clock, regardless of the system and regardless of the fact that only older version of Android have problem with it. The informative message that the checks is done is also unnecessary.
2. In Travis (.travis.yml) there is a build definition which will be done also on systems that require also posix threads and monotonic clock. Therefore in the cmake command that is called there the -DENABLE_MONOTONIC_CLOCK=ON must be added, otherwise some builds will fail.

Regarding the second point here, should I go and modify the .travis.yml file to set ENABLE_MONOTONIC_CLOCK to OFF for those that don’t need it, such as when the operating system is: osx?

[ethouris]

Regarding the second point here, should I go and modify the .travis.yml file to set ENABLE_MONOTONIC_CLOCK to OFF for those that don’t need it, such as when the operating system is: osx?

Not sure if there are any configurations where monotonic clock isn't available - I don't think so. So you should be able to add this simply to the overall call to cmake command; worst case it will be ignored. Hard to say, how it will turn out, we'll fix that later if need be.

[maxsharabayko]

Why do you disable the monotonic clock in CI builds?

[ethouris]

This must be enabled explicitly if we want to have monotonic clock enabled by default. Unless you think it is still better to just go on with default non-monotonic, if it was detected as not available (as it was so previously), but if so, then the check for this function must be also included in the check resulting in default monotonic clock OFF.

[lilinxiong]

here!

Of course, you can also reopen it and give it a try…

[cl-ment]

@lilinxiong could you please try #3152 and let us know if it fixes your issue and compiles in your environment?