On Sat, Oct 27, 2018 at 5:16 PM Mark Harris <mh-aus...@osj.us> wrote: > > 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
The two message queue functions are directly implemented with a system call on Linux at least, so I'm not sure that we should make new versions of these unless we get the underlying system call to accept different clocks. I believe the posix tracing functions are marked as obsolescent, so it seems to be best to leave them alone as well. I agree with the creating these same variants for other four functions. >> > > >> > > (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 pthread_cond_timedwait_onclock() is my top suggestion. It makes it clear that this is a modification to the parent pthread_cond_timedwait() functions and that its semantics should be identical with the change that it waits on the provided clock as opposed to the one used during initialization. I agree with moving this forward to the next required step. We can trivially implement them in the Android libc.
