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.

Reply via email to