On Sat, Oct 27, 2018 at 5:16 PM Mark Harris wrote:
>
> 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
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.
On Tue, Oct 9, 2018 at 6:19 AM Mike Crowe wrote:
>
> On Monday 08 October 2018 at 22:06:10 -0400, Daniel Eischen wrote:
> >
> > > On Oct 8, 2018, at 1:43 PM, enh wrote:
> > >
> > >> On Sat, Oct 6, 2018 at 12:09 PM Mike Crowe
> > >> wrote:
> > >>
> > >>> On Wednesday 12 September 2018 at
On Monday 08 October 2018 at 22:06:10 -0400, Daniel Eischen wrote:
>
> > On Oct 8, 2018, at 1:43 PM, enh wrote:
> >
> >> On Sat, Oct 6, 2018 at 12:09 PM Mike Crowe
> >> wrote:
> >>
> >>> On Wednesday 12 September 2018 at 13:47:59 -0700, Tom Cherry wrote:
> On Wed, Sep 12, 2018 at 11:56
> On Oct 8, 2018, at 1:43 PM, enh wrote:
>
>> On Sat, Oct 6, 2018 at 12:09 PM Mike Crowe
>> wrote:
>>
>>> On Wednesday 12 September 2018 at 13:47:59 -0700, Tom Cherry wrote:
On Wed, Sep 12, 2018 at 11:56 AM Mike Crowe
wrote:
>
> We (libc team for Android) have observed
On Sat, Oct 6, 2018 at 12:09 PM Mike Crowe wrote:
>
> On Wednesday 12 September 2018 at 13:47:59 -0700, Tom Cherry wrote:
> > On Wed, Sep 12, 2018 at 11:56 AM Mike Crowe
> > wrote:
> > >
> > > On Wednesday 12 September 2018 at 11:29:26 -0700, Tom Cherry wrote:
> > > > On Sun, Sep 9, 2018 at
On Sun, Oct 7, 2018 at 6:09 AM Mike Crowe
wrote:
> On Saturday 06 October 2018 at 17:43:06 -0400, Daniel Eischen wrote:
> >
> > > On Oct 6, 2018, at 3:00 PM, Mike Crowe
> wrote:
> > >
> > > Thank you for your detailed responses and patch links. I'm sorry it's
> taken
> > > me so long to
On Saturday 06 October 2018 at 17:43:06 -0400, Daniel Eischen wrote:
>
> > On Oct 6, 2018, at 3:00 PM, Mike Crowe wrote:
> >
> > Thank you for your detailed responses and patch links. I'm sorry it's taken
> > me so long to respond. I was waiting to see if there were any other
> > responses.
>
Sent from my iPhone
> On Oct 6, 2018, at 5:43 PM, Daniel Eischen wrote:
>
>
>> On Oct 6, 2018, at 3:00 PM, Mike Crowe wrote:
>>
>> Thank you for your detailed responses and patch links. I'm sorry it's taken
>> me so long to respond. I was waiting to see if there were any other
>>
On Wednesday 12 September 2018 at 13:47:59 -0700, Tom Cherry wrote:
> On Wed, Sep 12, 2018 at 11:56 AM Mike Crowe
> wrote:
> >
> > On Wednesday 12 September 2018 at 11:29:26 -0700, Tom Cherry wrote:
> > > On Sun, Sep 9, 2018 at 8:28 AM Mike Crowe
> > > wrote:
> > > >
> > > > On Thursday 30
On Wed, Sep 12, 2018 at 11:56 AM Mike Crowe wrote:
>
> On Wednesday 12 September 2018 at 11:29:26 -0700, Tom Cherry wrote:
> > On Sun, Sep 9, 2018 at 8:28 AM Mike Crowe
> > wrote:
> > >
> > > On Thursday 30 August 2018 at 21:10:48 +0100, Mike Crowe wrote:
> > > > C++11's
On Wednesday 12 September 2018 at 11:29:26 -0700, Tom Cherry wrote:
> On Sun, Sep 9, 2018 at 8:28 AM Mike Crowe wrote:
> >
> > On Thursday 30 August 2018 at 21:10:48 +0100, Mike Crowe wrote:
> > > C++11's std::condition_variable, std::timed_mutex and
> > > std::recursive_timed_mutex support
On Sun, Sep 9, 2018 at 8:28 AM Mike Crowe wrote:
>
> On Thursday 30 August 2018 at 21:10:48 +0100, Mike Crowe wrote:
> > C++11's std::condition_variable, std::timed_mutex and
> > std::recursive_timed_mutex support waiting with a timeout specified using
> > an arbitrary clock. It's common to use
On Thursday 30 August 2018 at 21:10:48 +0100, Mike Crowe wrote:
> C++11's std::condition_variable, std::timed_mutex and
> std::recursive_timed_mutex support waiting with a timeout specified using
> an arbitrary clock. It's common to use std::chrono::steady_clock (which
> corresponds to
19 matches
Mail list logo