On Sat, 27 Oct 2018 at 13:14, Mike Crowe
wrote:
> On Saturday 27 October 2018 at 15:26:07 -0400, Daniel Eischen wrote:
> >
> > > On Oct 27, 2018, at 12:14 PM, Mike Crowe
> wrote:
> > > Looking through POSIX Base Specifications Issue 7, I
> > > believe that the following other functions lack a
On Saturday 27 October 2018 at 17:07:00 -0400, Daniel Eischen wrote:
> 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
>
> On Oct 27, 2018, at 4:13 PM, Mike Crowe wrote:
>
>> On Saturday 27 October 2018 at 15:26:07 -0400, Daniel Eischen wrote:
>>
>>> On Oct 27, 2018, at 12:14 PM, Mike Crowe
>>> wrote:
>>> Looking through POSIX Base Specifications Issue 7, I
>>> believe that the following other functions lack
On Saturday 27 October 2018 at 15:26:07 -0400, Daniel Eischen wrote:
>
> > On Oct 27, 2018, at 12:14 PM, Mike Crowe
> > 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
> On Oct 27, 2018, at 12:14 PM, Mike Crowe wrote:
>
> On Tue, Oct 9, 2018 at 6:19 AM Mike Crowe 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
On Tue, Oct 9, 2018 at 6:19 AM Mike Crowe 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.
