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 > 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. I think it would be best for a supplied clock to override one set in the attributes. Returning an error would require extra state to be kept and checked, which would unnecessary complicate the implementation. I don't think there's any hurry to deprecate the attribute, although that may make sense eventually. I don't see any particular reason to add a clock attribute for mutexes if the above functions are added. Anyone who finds it laborious to pass the extra parameter can use a macro or wrapper function. Thanks. Mike.
