[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 3 Aug 2016 23:47:07 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
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 <nsz@...t70.net> wrote:
> >
> > * Ward Willats <musl@...dco.com> [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.
> > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#887
> > 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.
Rich
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.
