Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <000E3F7F-D1BA-4B68-9BD2-9E69A792A080@wardco.com>
Date: Wed, 3 Aug 2016 10:29:45 -0700
From: Ward Willats <musl@...dco.com>
To: musl@...ts.openwall.com
Subject: Re: std::condition_variable::wait_for() breakage when system_clock changes C++11 MIPS


> 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! :) 

Anyway to each their own. I'll copy this problem over to libstdc++ library as Patrick suggested w/appropriate versioning. Thanks for the use of the hall.

Best,

-- Ward



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.