From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65409 invoked by alias); 11 Mar 2019 17:35:12 -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 65397 invoked by uid 89); 11 Mar 2019 17:35:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=speedy, facilitate, sane X-HELO: mx2.freebsd.org Received: from mx2.freebsd.org (HELO mx2.freebsd.org) (8.8.178.116) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Mar 2019 17:35:11 +0000 Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id B8741A1805; Mon, 11 Mar 2019 17:35:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08C08717F7; Mon, 11 Mar 2019 17:35:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 9307916545; Mon, 11 Mar 2019 17:35:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [RFC 0/6] Demangle minimal symbol names in worker threads To: Eli Zaretskii , Tom Tromey Cc: gdb-patches@sourceware.org References: <20190309172300.2764-1-tom@tromey.com> <83tvgb7we9.fsf@gnu.org> From: John Baldwin Openpgp: preference=signencrypt Message-ID: <78689a07-247d-7481-75b8-416ed605a879@FreeBSD.org> Date: Mon, 11 Mar 2019 17:35:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <83tvgb7we9.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 08C08717F7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00225.txt.bz2 On 3/9/19 10:09 AM, Eli Zaretskii wrote: >> From: Tom Tromey >> Date: Sat, 9 Mar 2019 10:22:54 -0700 >> >> I've thought for a while that gdb should take advantage of multiple >> cores in order to speed up its processing. This series is some >> initial work in that direction. >> >> In particular, this patch arranges to do the demangling for minimal >> symbols in worker threads. I chose this because it seemed relatively >> simple to reason about, as the demangler is already mostly thread-safe >> (except, as it turns out, the Ada demangler, which is fixed in this >> series). It isn't actually a very important thing to speed up, as >> minimal symbol reading is already reasonably speedy; but I thought it >> best to start with something straightforward to facilitate flushing >> out thread safety bugs. > > Thanks, but is std::thread portable enough? E.g., I recall problems > with it in MinGW. > > Same question regarding delivering signals to threads. I can't speak to MinGW, but the signal in question here is a synchronous SIGSEGV signal due to a page fault or the like and in POSIX systems that is always sent to the thread executing the faulting instruction (and that is the only sane semantic since the thread can't execute any more instructions until the signal is resolved). -- John Baldwin