From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15918 invoked by alias); 17 Apr 2019 18:29:36 -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 15905 invoked by uid 89); 17 Apr 2019 18:29:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=shut, pay 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, 17 Apr 2019 18:29:34 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGpJL-0006A4-Rs; Wed, 17 Apr 2019 14:29:31 -0400 Received: from [176.228.60.248] (port=4362 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hGpJI-0000In-JP; Wed, 17 Apr 2019 14:29:30 -0400 Date: Wed, 17 Apr 2019 18:29:00 -0000 Message-Id: <83wojseb9c.fsf@gnu.org> From: Eli Zaretskii To: Joel Brobecker CC: gdb-patches@sourceware.org In-reply-to: <20190417173842.GA14817@adacore.com> (message from Joel Brobecker on Wed, 17 Apr 2019 10:38:42 -0700) Subject: Re: [RFA 2/2][master only] gdb/windows-nat.c: Get rid of main_thread_id global 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00299.txt.bz2 > Date: Wed, 17 Apr 2019 10:38:42 -0700 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > It happens completely randomly, and in all cases, the program itself > has a main program which waits for all software threads to complete > before itself terminating. Not sure what Windows is doing under > the hood. At program termination time, all kinds of irregularities could happen, especially if the program doesn't exit by exiting 'main' -- because AFAIK doing the latter causes CRT to explicitly shut down all the other threads. But there's little doubt in my mind that the thread whose ID is reported by CREATE_PROCESS_DEBUG_EVENT is the main thread. > If I understand you correctly, you want to preserve the global > so we can avoid those notifications. In my opinion, doing that > just for the purpose of filtering one notification is simply > not worth the trouble of keeping a global around. Generally speaking, > we tend to try to avoid globals as much as we can, as they are hard to > track, and makes the code harder to understand and maintain. > Modifying the logic to use the main_thread_id global instead of > the kind of event is a step backwards, in my opinion. If the only problem is having the global variable, we could mark the main thread in some other way, that won't need the global. But yes, I think not announcing the main thread is a nice feature, and losing it due to the mess that happens at program exit (something to which most users won't pay attention anyway) would be a pity. I'd even agree to announcing the exit of the main thread, if we cannot come up with a better solution, if that could allow us avoid its announcement at program startup. The use case I have in mind is debugging a single-threaded program. It is jarring enough, when debugging such a program, to see GDB announcing threads started by the OS. It would be nice if we could avoid announcing the main thread. Thanks.