[PATCH] D29818: [libcxx] Threading support: Attempt to externalize system_clock::now() and steady_clock::now() implementations

[Asiri Rathnayake via Phabricator via cfe-commits]

rmaprath added a comment.

Hi @EricWF

Apologies for the delay in replying to this.

In https://reviews.llvm.org/D29818#711795, @EricWF wrote:

> I really dislike that `__libcpp_clock_monotonic` and `__libcpp_clock_realtime` are never declared, and are expected to be magically defined by the external threading header.
>  This makes the configuration seem incorrect and unused.


This I can address by conditionally declaring these functions in the `__threading_support` header. But I think the the following assessment is not right:

> Also the previous threading support changes were beneficial to libc++ because they cleaned up and centralized the threading interface, making it easier to port libc++ to different
>  threading environments. This change has no such benefit.
> 
> Why should libc++ upstream this ARM specific configuration need?

Currently `chrono.cpp` depends on more than what a standard C library provides (`clock_gettime()` is specific to Unix, it is not part of the C standard), so this is about general portability of `libc++` and not ARM specific.

Anyone porting `libc++` into a bare-metal (or RTOS) environment will have to deal with this, so it would make sense to provide an external API for this? Of course, the approach proposed in this patch might not be the only way (or the best way) to do it.

WDYT?

/ Asiri


https://reviews.llvm.org/D29818