From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128522 invoked by alias); 22 Apr 2019 14:24:50 -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 128513 invoked by uid 89); 22 Apr 2019 14:24:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=silent, H*f:sk:9c75d15, process_, _iff 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 ESMTP; Mon, 22 Apr 2019 14:24:49 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1372583F3D; Mon, 22 Apr 2019 14:24:48 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1150B19C5A; Mon, 22 Apr 2019 14:24:46 +0000 (UTC) Subject: Re: [RFA 2/2][master only] gdb/windows-nat.c: Get rid of main_thread_id global To: Joel Brobecker References: <1555453982-77808-1-git-send-email-brobecker@adacore.com> <1555453982-77808-3-git-send-email-brobecker@adacore.com> <83imvcg0ud.fsf@gnu.org> <20190417173842.GA14817@adacore.com> <83wojseb9c.fsf@gnu.org> <20190417221729.GA5839@adacore.com> <9c75d158-6a73-d414-4cb2-17297d4576c6@redhat.com> <20190419204326.GA9601@adacore.com> Cc: Eli Zaretskii , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 22 Apr 2019 14:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190419204326.GA9601@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-04/txt/msg00420.txt.bz2 On 4/19/19 9:43 PM, Joel Brobecker wrote: >>> - patch #3 (master only): Tag the main thread, and silence >>> the thread-exit notification of the thread that got tagged. >>> Depending on the implementation, this patch would potentially >>> be acceptable for 8.3, but might need extra work to apply. >>> I think we've had enough problems with 8.3 as it is, I don't >>> want to add more things to do, so I vote OUT for 8.3. >> >> This doesn't seem right to me, given that the main thread may >> legitimately exit before other threads. If this approach is taken, >> maybe tweak it a bit: >> >> silence the thread-exit notification of the thread that got tagged >> _iff there are no other threads in the process_. > > Wouldn't that be confusing? What would happen in that case is that > we end up getting a a thread-exit notification with a thread ID > for which there hasn't been a new-thread notification. Without > knowing the implementation details of how GDB decides to silence > or not thread notifications, people are going to ask themselves > where the thread that exited came from, and why we didn't see > a new-thread notification for it before. > > To decide which approach we want to take - what would be the issue > if we decided to silence the main thread's exit notification while > some other threads might still be alive? In my view, it's OK to not let the user know the main thread is exiting when it's the last thread in the process because the process is exiting right away. But if the main thread is not the last thread, then the process is going to stay around. And in that case, if a user wants thread exit notifications, I think it just makes sense to let the user know a thread exited, more so since the main thread of a program tends to be its most "important" thread. I don't see the asymmetry (silent at creation, not silent at destruction) in this particular case as surprising -- when the program is starting up, there's only one thread, and I don't think users are surprised to find that after running to main there's already one thread in the thread list. I also think that if we included the GDB thread id (and name) in thread creation/exited notifications, similar to the output of inferior start/exit notifications, then users would be even less surprised with the asymmetry, as users could clearly tell that it's the main thread that is exiting: Currently: [Thread 48192.0xd100 exited with code 1] With gdb thread id and name: [Thread 1.1 (48192.0xd100 "the thread's name") exited with code 1] I think that would be a good overall change, regardless. > Assuming Pedro is making > a valid point, I think we should go back to pre-8.3 behavior, and > show all thread create/exit notifications, including for the main > thread. Thanks, Pedro Alves