[Android] Deprecate pthread_cond_timedwait_monotonic

The Android team is deprecating pthread_cond_timedwait_monotonic in favor of the more standard pthread_condattr_getclock.

Update usage in Chromium such that it will use the standards based code path when it's present.
    
Bug:349865

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255428

[benm (inactive), 2014-03-05 15:12:06]

ptal

[Nico, 2014-03-05 18:24:25]

Let's not reference internal bugs in CL descriptions. Either file a public bug
or make the cl description a tiny bit longer (describe that
AVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC is defined only on _older_ android
releases).

Will this work correctly with older android versions? pthread is probably not
statically linked, is it?

[benm (inactive), 2014-03-06 11:33:17]

On 2014/03/05 18:24:25, Nico wrote:
> Let's not reference internal bugs in CL descriptions. Either file a public bug
> or make the cl description a tiny bit longer (describe that
> AVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC is defined only on _older_ android
> releases).
> 
> Will this work correctly with older android versions? pthread is probably not
> statically linked, is it?

Thanks Nico, filed a crbug and updated the issue description.

I've tested the CL in both an environment where pthread_cond_timedwait_monotonic
was available and unavailable and things look good. Current versions of the NDK
that Chrome uses to build still have pthread_cond_timedwait_monotonic and define
HAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC to 1; so there should be no behavior
change to Chrome with this CL at this time. A future NDK update will remove the
function and set HAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC to 0, at which point
we'll take the standard POSIX approach. And if we move to use that NDK wholesale
(which I guess we will) we can remove the conditional compilation at that point,
I guess. I could keep the bug open/add a TODO to that effect, if you like.

[(unused - use chromium), 2014-03-06 14:41:53]

If you build chrome with this new ndk, will it still run on current android
versions?
On Mar 6, 2014 3:33 AM, <benm@chromium.org> wrote:

> On 2014/03/05 18:24:25, Nico wrote:
>
>> Let's not reference internal bugs in CL descriptions. Either file a
>> public bug
>> or make the cl description a tiny bit longer (describe that
>> AVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC is defined only on _older_ android
>> releases).
>>
>
>  Will this work correctly with older android versions? pthread is probably
>> not
>> statically linked, is it?
>>
>
> Thanks Nico, filed a crbug and updated the issue description.
>
> I've tested the CL in both an environment where pthread_cond_timedwait_
> monotonic
> was available and unavailable and things look good. Current versions of
> the NDK
> that Chrome uses to build still have pthread_cond_timedwait_monotonic and
> define
> HAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC to 1; so there should be no behavior
> change to Chrome with this CL at this time. A future NDK update will
> remove the
> function and set HAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC to 0, at which
> point
> we'll take the standard POSIX approach. And if we move to use that NDK
> wholesale
> (which I guess we will) we can remove the conditional compilation at that
> point,
> I guess. I could keep the bug open/add a TODO to that effect, if you like.
>
> https://codereview.chromium.org/183763031/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[benm (inactive), 2014-03-06 16:02:03]

On 2014/03/06 14:41:53, thakis wrote:
> If you build chrome with this new ndk, will it still run on current android
> versions?

Yes. Like the Java SDK, NDK apps have a target API version and that will decide
which version of the pthread headers are used at compile time. The new NDK will
still have the old symbol in libc.so, just it won't be exposed in the latest
version of the header. That means there will only be a change to Chrome if and
when it updates it's target API version to something >= the one where
HAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC gets set to 0 and
pthread_condattr_getclock is added.  

If Chrome updates to the new NDK but does not change the API version, then it
will get the older headers and old behavior.
If Chrome updates to the new NDK but does change its target API, then it won't
install on older devices where pthread_condattr_getclock is not available.

The motivation for doing this now is to enable the downstream WebView build to
start making use of pthread_condattr_getclock sooner, as it builds against the
platform rather than the NDK.

[Nico, 2014-03-06 16:15:03]

lgtm

Thanks for explaining!

[benm (inactive), 2014-03-06 16:20:02]

The CQ bit was checked by benm@chromium.org

[commit-bot: I haz the power, 2014-03-06 16:20:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/benm@chromium.org/183763031/40001

[commit-bot: I haz the power, 2014-03-06 20:49:00]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/benm@chromium.org/183763031/40001

[commit-bot: I haz the power, 2014-03-06 21:12:02]

Change committed as 255428