On Saturday 27 October 2018 at 17:07:00 -0400, Daniel Eischen wrote:
> The nice thing about being able to set the clock in an attribute or some
> other way (e.g., pthread_set_preferred_clock) is that you only have to do
> it once, as opposed to potentially modifying lots of other code, even in
> libraries outside your scope. If you're writing a library that waits for
> events for the caller, you don't know what clock to use unless you add it
> to your API. Allowing the clock to be set on a per-thread (or even
> process) basis, might make things easier. Absolute times wouldn't really
> be helped by this though, as you still need to get the time for the
> correct clock.

I've written another blog post[1] that explains why the clock to use is a
property of the wait, although it doesn't address your suggestion directly.
The C++ standard library behaves as if "struct timespec" also contained
clockid_t, although the clock is part of the type so the compiler handles
it with no runtime overhead. This means that C++ libraries can be clock

I think that being able to set these things for a process or a thread makes
writing generic libraries harder. Some libraries may actively want to
choose which clock to use since their use of condition variables is
entirely invisible to the calling application. Others may want to expose
the clock to use. At the moment, neither is really possible for anything
but condition variables, and condition variables need to know the clock to
use in advance.




Reply via email to