From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10349 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy 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 13:27:52 +0200 Message-ID: <20160803112751.GX19691@port70.net> References: <3008FD15-1C92-4870-9CD9-BC8B694ACCD0@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 1470223698 4002 195.159.176.226 (3 Aug 2016 11:28:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 Aug 2016 11:28:18 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) To: musl@lists.openwall.com Original-X-From: musl-return-10362-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 03 13:28:13 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 1bUuLN-0000Vx-8B for gllmg-musl@m.gmane.org; Wed, 03 Aug 2016 13:28:13 +0200 Original-Received: (qmail 9726 invoked by uid 550); 3 Aug 2016 11:28:10 -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 9706 invoked from network); 3 Aug 2016 11:28:09 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <3008FD15-1C92-4870-9CD9-BC8B694ACCD0@wardco.com> Xref: news.gmane.org gmane.linux.lib.musl.general:10349 Archived-At: * Ward Willats [2016-08-02 16:33:29 -0700]: > > We are running a C++ 11 app on a MIPS-based Linux/OpenWRT platform and linking against MUSCL 1.1.12 and libstdc++ v3. On cold boot, our system clock is often some random time in the future until ntpd or other software corrects it. This led to odd behavior and this experiment: > > If I use the busybox "date --set" to move our system's clock 24 hours into the future, and then call: > > std::condition_variable::wait_for() with the pre-canned std::chrono::duration, std::chrono::milliseconds( 120000 ), as a 2 minute wait timeout AND then... > > ...set the clock BACK 24 hours to the correct/current time with ntpd, wait_for() doesn't return after 2 minutes (assuming no notify() of course). (Presumably, wait_for() is using system_clock, and not steady_clock, and will fire in 24 hours + 2 minutes -- but I haven't waited to find out.) > > However, if I repeat this experiment and call std::condition_variable::wait_until() with a timeout time_point calculated as std::chrono::steady_clock::now() + std::chrono::milliseconds( 120000 ), which neatly binds a steady_clock ref into the time_point, it does indeed fire in 2 minutes after the clock is set back, as expected. > > 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.