On Thu, 20 Apr 2023 at 08:45, Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I wanted to say that I faced this problem as well, and my solution was
> to define clock traits that, among other things, allowed to know the
> clockid_t corresponding to a given chrono clock.


User code can't know this, certainly not as a compile-time constant. It
might depend on runtime conditions, such as the kernel version the
application runs on, and the system config.

e.g. std::chrono::tai_clock might use Linux's CLOCK_TAI if the kernel
supports it, and if the kernel's tai offset "roughly correct" (i.e. some
system process like chrony has actually adjusted the tai offset, rather
than leaving it at zero which is the value on boot). That is something that
can only be detected at runtime inside the std::lib.



> Also, in that code base
> we defined our own clock types that explicitly use clock_gettime with
> various clock id constants, and we don't use std::chrono clocks at all.
> Granted, that code base is mostly Linux-only, and definitely not
> compatible to Windows. It may run on other POSIX systems, but it was
> never tested.
>
> On 4/20/23 03:20, Thiago Macieira via Std-Proposals wrote:
> > In refactoring some older Qt code that directly used clock_gettime() to
> use
> > std::chrono::steady_clock, I stumbled upon a limitation: I need to pass
> clock
> > time points to certain low-level functions. The one in particular I was
> > looking at is pthread_cond_timedwait(), whose timestamp must match the
> POSIX
> > clock set with pthread_condattr_setclock(). I wrote the code assuming
> that in
> > all systems std::chrono::steady_clock was the same as CLOCK_MONOTONIC,
> but
> > this isn't true in either Darwin systems (libc++ uses
> CLOCK_MONOTONIC_RAW) or
> > QNX (no clue what happens there).
> >
> > Therefore, I'd like to propose that steady_clock add an extra method
> that
> > returns the clock ID. It could be as simple as:
> >
> > [[pure]] static int clock_base();
>
> I think, it would be better to return clockid_t, and define the type to
> int or whatever on platforms that don't define it yet. Returning int
> would be suboptimal on (or incompatible with) platforms that define
> clockid_t to a different type. It should be strongly implied (perhaps,
> in a non-normative note) that this clockid_t type is intended to
> correspond to POSIX clockid_t, and the set of supported values matches
> the CLOCK_* constants.
>
> Also, clock_id() name seems more appropriate, as the clock type does not
> only affect the epoch (base) time point, but also the precision (e.g.
> *_COARSE clocks) and time progression (e.g. *_CPUTIME_ID clocks).
>
> Perhaps, it would be even better to add a static constant to a clock
> type rather than a static method. This would allow it to use the id in
> template parameters.
>

Then it would have to be given an invalid value for many clocks (including
chrono::steady_clock!), because it can't be known at compile-time.