Sent from my iPhone
> On Oct 6, 2018, at 5:43 PM, Daniel Eischen <deisc...@freebsd.org> wrote:
>
>
>> On Oct 6, 2018, at 3:00 PM, Mike Crowe <theopengr...@mac.mcrowe.com> wrote:
>>
>> Thank you for your detailed responses and patch links. I'm sorry it's taken
>> me so long to respond. I was waiting to see if there were any other
>> responses.
>
> Aside from what may be needed by the implementation for the proposed C++
> standard functionality, I don't understand why initializing a mutex or
> condition variable (via the attribute) with the desired clock is not
> sufficient. I can see adding an analogue to pthread_condattr_setclock() for
> a mutex attribute, but what is the real need to provide both real-time and
> monotonic sleeps on the same mutex or condition variable? Initialize them
> once with the clock you want, and be done with it.
>
> I'd almost rather see the timespec changed (controversial much?!) to add the
> clock id rather than keep adding new interfaces to support waits/sleeps on
> different clocks. Or maybe to provide a hint to the implementation as to
> what clock to use on a per-thread basis via something like
> pthread_attr_setpreferredclock() and pthread_setpreferredclock(). If you had
> these, I suppose you could implement the C++ functionality by saving the
> current thread's preferred clock, setting it to the desired clock, calling
> the mutex lock or CV wait function, then restoring the thread's clock before
> returning to the caller.
>
> --
> DE
