Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 3 Aug 2016 23:47:07 -0400
From: Rich Felker <>
Subject: Re: std::condition_variable::wait_for() breakage when
 system_clock changes C++11 MIPS

On Wed, Aug 03, 2016 at 10:29:45AM -0700, Ward Willats wrote:
> > On Aug 3, 2016, at 4:27 AM, Szabolcs Nagy <> wrote:
> > 
> > * Ward Willats <> [2016-08-02 16:33:29 -0700]:
> >> 
> >> In short, the std::condition_variable API that takes a
> >> std::chrono:duration does not work, but the one that takes a
> >> std::chrono::time_point does.
> >> 
> > 
> > this is a libstdc++ issue so the gcc version matters.
> > (i can see condvar related issues fixed in gcc bugzilla)
> > 
> > there are several issues with the c++11 condvar timeout api e.g.
> >
> > so i'd avoid using c++, it's just a broken abstraction layer
> > on top of the pthreads api with poor specification.. meanwhile
> > pthreads works fine and is portable.
> > 
> Thanks. Don't need the portability, but <thread> is arguably MORE
> portable -- depending on the platforms of interest. Anyway the
> pthread_t is available if we want to get down and dirty -- and we do
> sometimes (e.g. thread cancelling, naming). The link just
> demonstrates that poor-old pthreads can't model the rich abstraction
> of C++ without work arounds! :)

pthread cond variables can wait on CLOCK_REALTIME or CLOCK_MONOTONIC,
addressing this issue, always with "until" instead of "for" semantics
(but for monotonic, "for" and "until" are functionally equivalent).
However musl may not correctly handle the case where the realtime
clock changes during the wait. I'll look into this.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.