On Monday 29 October 2018 at 13:42:59 -0700, Tom Cherry wrote: > On Sat, Oct 27, 2018 at 5:16 PM Mark Harris <mh-aus...@osj.us> wrote: > > > > On Sat, 27 Oct 2018 at 13:14, Mike Crowe <theopengr...@mac.mcrowe.com> > > wrote: > >> > >> On Saturday 27 October 2018 at 15:26:07 -0400, Daniel Eischen wrote: > >> > > >> > > On Oct 27, 2018, at 12:14 PM, Mike Crowe <theopengr...@mac.mcrowe.com> > >> > > wrote: > >> > > 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 > > The two message queue functions are directly implemented with a system > call on Linux at least, so I'm not sure that we should make new > versions of these unless we get the underlying system call to accept > different clocks.
The libc implementation can accept the clock parameter, but fail if it is passed anything other then CLOCK_REALTIME. Maybe one day the system call can gain CLOCK_MONOTONIC support, and then support can be implemented in libc. If we're going to add these clockid_t parameters, then we might as well add them everywhere. > I believe the posix tracing functions are marked as > obsolescent, so it seems to be best to leave them alone as well. That makes sense to me. Let me refine that "everywhere" to not include stuff that's deprecated. :) > I agree with the creating these same variants for other four functions. So, it looks like we just need to agree on the names then, and I can try to write some words. I shall endeavour to write a summary of the naming options over the weekend. Thanks. Mike.
