> 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 

>> 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.


Reply via email to