From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10355 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: std::condition_variable::wait_for() breakage when system_clock changes C++11 MIPS Date: Wed, 3 Aug 2016 23:47:07 -0400 Message-ID: <20160804034706.GF15995@brightrain.aerifal.cx> References: <3008FD15-1C92-4870-9CD9-BC8B694ACCD0@wardco.com> <20160803112751.GX19691@port70.net> <000E3F7F-D1BA-4B68-9BD2-9E69A792A080@wardco.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1470282520 12326 195.159.176.226 (4 Aug 2016 03:48:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 4 Aug 2016 03:48:40 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10368-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 04 05:48:36 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1bV9cw-0000at-9S for gllmg-musl@m.gmane.org; Thu, 04 Aug 2016 05:47:22 +0200 Original-Received: (qmail 1574 invoked by uid 550); 4 Aug 2016 03:47:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1556 invoked from network); 4 Aug 2016 03:47:20 -0000 Content-Disposition: inline In-Reply-To: <000E3F7F-D1BA-4B68-9BD2-9E69A792A080@wardco.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10355 Archived-At: 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. > > 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 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