> On Oct 27, 2018, at 4:13 PM, 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
Either one of those sounds good to me, I might prefer the latter if I had to choose. >> 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. The nice thing about being able to set the clock in an attribute or some other way (e.g., pthread_set_preferred_clock) is that you only have to do it once, as opposed to potentially modifying lots of other code, even in libraries outside your scope. If you're writing a library that waits for events for the caller, you don't know what clock to use unless you add it to your API. Allowing the clock to be set on a per-thread (or even process) basis, might make things easier. Absolute times wouldn't really be helped by this though, as you still need to get the time for the correct clock. -- DE
