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:


Although, if you consider the prefix to contain multiple words then they
would be:


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



Reply via email to