From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54654 invoked by alias); 2 May 2015 18:56:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 54635 invoked by uid 89); 2 May 2015 18:56:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 02 May 2015 18:56:30 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t42IuSUJ010383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 2 May 2015 14:56:28 -0400 Received: from localhost (ovpn-116-62.ams2.redhat.com [10.36.116.62]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t42IuRCU020334; Sat, 2 May 2015 14:56:28 -0400 Date: Sat, 02 May 2015 18:56:00 -0000 From: Jonathan Wakely To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: [patch] libstdc++/56117 make std::async launch new threads by default Message-ID: <20150502185627.GG3618@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0ZSpXV6RUUo6PuQK" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-05/txt/msg00151.txt.bz2 --0ZSpXV6RUUo6PuQK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-length: 558 One last patch before I head to Lenexa, this fixes the long standing not-a-bug that our default launch policy is launch::deferred. This way std::async with no explicit policy or with any policy that contains launch::async will run in a new thread. Apparently libc++ does the same and they aren't getting lots of complaints about fork-bombs, so let's try the same thing. If people don't like it we have plenty of time in stage 1 to reconsider. Tested x86_64-linux and powerpc64le-linux, I'm going to commit this to trunk unless someone strongly objects. --0ZSpXV6RUUo6PuQK Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" Content-length: 885 commit cb6dfe604295873cebd5b3a53b10b1e882eb3cff Author: Jonathan Wakely Date: Sat May 2 19:27:10 2015 +0100 PR libstdc++/51617 * include/std/future (async): Change default policy to launch::async. diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future index fc3f816..a67db98 100644 --- a/libstdc++-v3/include/std/future +++ b/libstdc++-v3/include/std/future @@ -1704,7 +1704,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION { typedef typename result_of<_Fn(_Args...)>::type result_type; std::shared_ptr<__future_base::_State_base> __state; - if ((__policy & (launch::async|launch::deferred)) == launch::async) + if ((__policy & launch::async) == launch::async) { __state = __future_base::_S_make_async_state(std::__bind_simple( std::forward<_Fn>(__fn), std::forward<_Args>(__args)...)); --0ZSpXV6RUUo6PuQK--