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 agnostic. 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. Thanks. Mike. [1] http://randombitsofuselessinformation.blogspot.com/2018/10/the-clock-used-for-waiting-on-condition.html
