On Tue, Oct 9, 2018 at 6:19 AM Mike Crowe <theopengr...@mac.mcrowe.com> wrote:
>> So, my favourite solution is to invent an equivalent of
>> pthread_cond_timedwait that accepts a clockid_t since it feels more
>> future-proof, but adding the Android pthread_cond_timedwait_monotonic
>> instead would solve my current problems.
On Tuesday 09 October 2018 at 10:16:38 -0700, Tom Cherry wrote:
> Despite my above intentions, I completely understand why POSIX widely
> would want a function that takes a clockid_t and fully support that
> idea. That would solve our issues too and if we can get libc++ to
> properly wait on CLOCK_MONOTONIC, then that's a huge step forward.
So, where do we go from here? I believe that I've responded to everyone
that raised objections.
I've read through the documents I could find on the Open Group web site,
but it's not clear to me what we need to do next.
Would it be better to propose the complete set of functions that are
missing the ability to wait on CLOCK_MONOTONIC in one go, along with
standard wording? 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.
int sem_timedwait_on_clock(sem_t *restrict sem,
clockid_t clock,
const struct timespec *restrict abstime)
int pthread_mutex_timedlock_on_clock(pthread_mutex_t *restrict mutex,
clockid_t clock,
const struct timespec *restrict abstime)
int pthread_rwlock_timedrdlock_on_clock(pthread_rwlock_t *restrict rwlock,
clockid_t clock,
const struct timespec *restrict abstime)
int pthread_rwlock_timedwrlock_on_clock(pthread_rwlock_t *restrict rwlock,
clockid_t clock,
const struct timespec *restrict abstime)
int pthread_cond_timedwait_on_clock(pthread_cond_t *restrict cond,
pthread_mutex_t *restrict mutex,
clockid_t clock,
const struct timespec *restrict abstime)
ssize_t mq_timedreceive_on_clock(mqd_t mqdes, char *restrict msg_ptr,
size_t msg_len,
unsigned int *restrict msg_prio,
clockid_t clock,
const struct timespec *restrict abs_timeout)
int mq_timedsend_on_clock(mqd_t mqdes, const char *restrict msg_ptr,
size_t msg_len, unsigned int msg_prio,
clockid_t clock,
const struct timespec *restrict abs_timeout)
int posix_trace_timedgetnext_event_on_clock(trace_id_t trid,
struct posix_trace_event_info
*restrict event,
void *restrict data, size_t
num_bytes,
size_t *restrict data_len,
int *restrict unavailable,
clockid_t clock,
const struct timespec *restrict
abstime);
If implementors are worried about the extra work required to implement
these new functions then perhaps only CLOCK_REALTIME should be mandatory so
they can just call their original implemenation in that case.
Any guidance as to where we go next gratefully received.
Thanks.
Mike.
