From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114994 invoked by alias); 22 Apr 2019 21:42:51 -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 114980 invoked by uid 89); 22 Apr 2019 21:42:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_JMF_BL autolearn=no version=3.3.1 spammy=compensate, 55pm, 55PM, H*r:sk:mailout X-HELO: mailout09.t-online.de Received: from mailout09.t-online.de (HELO mailout09.t-online.de) (194.25.134.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Apr 2019 21:42:49 +0000 Received: from fwd22.aul.t-online.de (fwd22.aul.t-online.de [172.20.26.127]) by mailout09.t-online.de (Postfix) with SMTP id 45295427AF2E; Mon, 22 Apr 2019 23:42:47 +0200 (CEST) Received: from localhost (XGr6sGZ6ohFh7sorOoQySuzeS0qNIjMLLIzyd-LvWuv3+VFmHeOF86Gp8xBm1nKgcV@[95.91.240.80]) by fwd22.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1hIgi0-0pMqRc0; Mon, 22 Apr 2019 23:42:40 +0200 Date: Mon, 22 Apr 2019 21:42:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Pedro Alves Cc: Joel Brobecker , Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: [RFA 2/2][master only] gdb/windows-nat.c: Get rid of main_thread_id global Message-ID: <20190422214607.GA2372@klara.mpi.htwm.de> References: <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> <20190422152327.GA10697@klara.mpi.htwm.de> <7f39cca0-c200-430e-e885-32cc347207d0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7f39cca0-c200-430e-e885-32cc347207d0@redhat.com> X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00428.txt.bz2 On Mon, Apr 22, 2019 at 06:28:55PM +0100, Pedro Alves wrote: > On 4/22/19 4:23 PM, André Pönitz wrote: > > On Mon, Apr 22, 2019 at 03:24:46PM +0100, Pedro Alves wrote: > >> I don't see the asymmetry (silent at creation, not silent at destruction) > >> in this particular case as surprising [...] > > > > It's not surprising, but it's inconsistent > > and causes extra work in > > cases one wants to mechanically examine such output. > > I'm curious about what extra work you're thinking of. As far as I understand it, any (non-MI) user wanting to keep track of running threads would need to find out which events are "not surprising" (for which version of GDB...) and mentally (or in code) "generate" the "missing" events. That's a kind of "work". > Can't think of anything significant. It's not significant, but less surprising to me personally, i.e. violating the principle of least astonishment. > But do note that this discussion does not affect MI. I understand that, and for thread related notifications MI is sufficient for my frontend purposes, but in general MI does not cover all functionality of CLI and already this discrepancy is a surprise to some degree. I'd rather see the differences go away over time, not to increase. > So what do you propose? My proposal kept these two ideas in mind: > > - be quiet wrt to threads with single-threaded programs. TBH, I don't see the necessity of this requirement. That would be two lines of noise per run. > - inform the user the main thread exited while other threads stay running. Also here, I don't see enough gain in one suppressed line of output to compensate for the inconsistency, this time even with a CLI user hat on. Andre'