> On Oct 27, 2018, at 12:14 PM, Mike Crowe <theopengr...@mac.mcrowe.com> wrote: > > On Tue, Oct 9, 2018 at 6:19 AM Mike Crowe <theopengr...@mac.mcrowe.com> wrote: >>> So, my favourite solution is to invent an equivalent of >>> pthread_cond_timedwait that accepts a clockid_t since it feels more >>> future-proof, but adding the Android pthread_cond_timedwait_monotonic >>> instead would solve my current problems. > >> On Tuesday 09 October 2018 at 10:16:38 -0700, Tom Cherry wrote: >> Despite my above intentions, I completely understand why POSIX widely >> would want a function that takes a clockid_t and fully support that >> idea. That would solve our issues too and if we can get libc++ to >> properly wait on CLOCK_MONOTONIC, then that's a huge step forward. > > So, where do we go from here? I believe that I've responded to everyone > that raised objections. > > I've read through the documents I could find on the Open Group web site, > but it's not clear to me what we need to do next. > > Would it be better to propose the complete set of functions that are > missing the ability to wait on CLOCK_MONOTONIC in one go, along with > standard wording?
I would tend to agree. > Looking through POSIX Base Specifications Issue 7, I > believe that the following other functions lack a way to use > CLOCK_MONOTONIC directly (and unlike pthread_cond_timedwait, I can see no > other way to make them do so): > > sem_timedwait > pthread_mutex_timedlock > pthread_rwlock_timedrdlock > pthread_rwlock_timedwrlock > mq_timedreceive > mq_timedsend > posix_trace_timedgetnext_event > > (Many other functions that take a struct timespec treat it as a relative > timeout.) Of these, I've also found it necessary to implement a version of > sem_timedwait that used CLOCK_MONOTONIC. > > I originally named my function pthread_cond_timedwaitonclock since it > seemed that running the words together matched what was happening with > "timedwait". Others suggested that it should be > pthread_cond_timedwait_on_clock. I've tried to apply that style in the > function prototypes below. I think at least the "on_clock" should be "onclock" or just "clock" for the same reason timedwait is not timed_wait. Perhaps "_cid" for clock_id? Also, "clock_" is prefixed to nanosleep for similar functionality, perhaps pthread_clock_cond_timedwait, etc instead of suffixing with "_clock" or "_onclock"? There is still the ability to set the clock in the condition variable attribute. Should this be deprecated in lieu of the other functionality? If not, which one takes precedence? Should mutex attributes also grow the ability to set the clock? For the second question, I'd assume that anything explicitly set in an "onclock" variant would override what was specified in the attribute, or perhaps return an error instead. -- DE
