From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43342 invoked by alias); 13 Mar 2019 15:38:49 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 43331 invoked by uid 89); 13 Mar 2019 15:38:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=worker, H*f:sk:83tvgb7, mingw-w64, mingww64 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Mar 2019 15:38:47 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h45xn-0006KI-5B; Wed, 13 Mar 2019 11:38:41 -0400 Received: from [176.228.60.248] (port=1599 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h45xl-0003FB-V6; Wed, 13 Mar 2019 11:38:38 -0400 Date: Wed, 13 Mar 2019 15:38:00 -0000 Message-Id: <83muly3htw.fsf@gnu.org> From: Eli Zaretskii To: tom@tromey.com CC: gdb-patches@sourceware.org In-reply-to: <83lg1k4vhx.fsf@gnu.org> (message from Eli Zaretskii on Tue, 12 Mar 2019 05:33:30 +0200) Subject: Re: [RFC 0/6] Demangle minimal symbol names in worker threads References: <20190309172300.2764-1-tom@tromey.com> <83tvgb7we9.fsf@gnu.org> <87ef7d8298.fsf@tromey.com> <83lg1k4vhx.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00270.txt.bz2 > Date: Tue, 12 Mar 2019 05:33:30 +0200 > From: Eli Zaretskii > CC: gdb-patches@sourceware.org > > > I asked around and learned that std::thread should work fine if you have > > winpthreads, which apparently is used by default for mingw-w64. > > > > I don't actually know much about the mingw world, so I don't know if > > that is good enough or not. Could you say? > > I could try. Here's the answer. The simple test program attached at the end doesn't compile: D:\usr\eli\data>g++ -c ./threaded-hello.cc ./threaded-hello.cc: In function 'int main()': ./threaded-hello.cc:12:8: error: 'thread' is not a member of 'std' std::thread t1(call_from_thread); ^~~~~~ ./threaded-hello.cc:12:8: note: suggested alternative: 'tera' std::thread t1(call_from_thread); ^~~~~~ tera ./threaded-hello.cc:15:3: error: 't1' was not declared in this scope t1.join(); ^~ ./threaded-hello.cc:15:3: note: suggested alternative: 'tm' t1.join(); ^~ tm So I think only MinGW64 might have support for std::thread, mingw.org's MinGW (which is what I'm using) definitely doesn't. > But regardless, I think we should allow for ports whose > std::thread is not up to the task, because evidently this is a > problematic area of libstdc++. It is IMO better to allow running this > code in a single thread than breaking the entire build on some > platform because other platforms might benefit from multiple execution > cores. This is still true. We could detect at configure time that std::thread isn't supported and revert to serial alternative code instead. Is that reasonable? If that is deemed too much of a maintenance burden, I could perhaps, with some guidance, implement a simple replacement using Win32 primitives, if all we need is to start a thread and then do the thread-join thing. Let me know what you think. Here's the program I used to test this: #include #include //This function will be called from a thread void call_from_thread() { std::cout << "Hello, World" << std::endl; } int main() { //Launch a thread std::thread t1(call_from_thread); //Join the thread with the main thread t1.join(); return 0; }