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 > > > > > > (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"? > > I think that the clock prefix has some benefits. This would mean: > > sem_clock_timedwait > pthread_clock_mutex_timedlock > pthread_clock_rwlock_timedrdlock > pthread_clock_rwlock_timedwrlock > mq_clock_timedreceive > mq_clock_timedsend > posix_clock_trace_timedgetnext_event > pthread_clock_cond_timedwait > > Although, if you consider the prefix to contain multiple words then they > would be: > > sem_clock_timedwait > pthread_mutex_clock_timedlock > pthread_rwlock_clock_timedrdlock > pthread_rwlock_clock_timedwrlock > mq_clock_timedreceive > mq_clock_timedsend > posix_trace_clock_timedgetnext_event > pthread_cond_clock_timedwait > How about just replacing "timed" with "clock"? sem_clockwait pthread_mutex_clocklock pthread_rwlock_clockrdlock pthread_rwlock_clockwrlock mq_clockreceive mq_clocksend posix_trace_clockgetnext_event pthread_cond_clockwait To me these names seem more appropriate, given that these calls wait until the specified clock reaches the specified absolute value. If the clock can be set, or if an implementation were to support using these with, say, CPUTIME clocks, then "timed" does not seem correct since it is not the time taken by the call but rather the behavior of the specified clock that is significant. - Mark