From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15601 invoked by alias); 28 May 2011 00:31:29 -0000 Received: (qmail 15587 invoked by uid 22791); 28 May 2011 00:31:28 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 28 May 2011 00:31:12 +0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/49204] New: remaining issues in X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Sat, 28 May 2011 00:32:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg02777.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D49204 Summary: remaining issues in Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: redi@gcc.gnu.org ReportedBy: redi@gcc.gnu.org (this is a placeholder and reminder to myself) We don't return future_status from the timed waiting functions. The requirements for async say: If the implementation chooses the launch::async policy, =E2=80=94 a call to a waiting function on an asynchronous return object = that shares the shared state created by this async call shall block until the associated thread has completed, as if joined (30.3.1.5); The current implementation doesn't meet this requirement, _Async_state::_M_do_run could make the state ready and unblock waiters before the thread completes. Proposed fix: _State_base::_M_wait() already calls _M_run_deferred() to give a deferred function a chance to run, we could add override it as _Async_state::_M_run_deferred() and join the thread. @@ -1325,7 +1325,7 @@ _M_thread(mem_fn(&_Async_state::_M_do_run), this) { } - ~_Async_state() { _M_thread.join(); } + ~_Async_state() { _M_join(); } private: void _M_do_run() @@ -1334,11 +1334,18 @@ _M_set_result(std::move(__setter)); } + void _M_run_deferred() + { _M_join(); } + + void _M_join() + { std::call_once(_M_once, &thread::join, ref(_M_thread)); } + template friend class _Task_setter; typedef typename __future_base::_Ptr<_Result<_Res>>::type _Ptr_type; _Ptr_type _M_result; std::function<_Res()> _M_fn; thread _M_thread; + once_flag _M_once; }; /// async That would ensure non-timed waiting functions block as if joined. It doesn't handle non-timed waiting functions, but I'm not convinced they should block.