From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4622 invoked by alias); 16 Jul 2008 13:23:50 -0000 Received: (qmail 4602 invoked by uid 22791); 16 Jul 2008 13:23:48 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 Jul 2008 13:23:31 +0000 Received: (qmail 10781 invoked from network); 16 Jul 2008 13:23:29 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jul 2008 13:23:29 -0000 From: Vladimir Prus To: gdb@sources.redhat.com Subject: Re: MI threads behaviour Date: Wed, 16 Jul 2008 13:23:00 -0000 User-Agent: KMail/1.9.9 References: <200806181601.52404.vladimir@codesourcery.com> <200807161652.24626.vladimir@codesourcery.com> <20080716130755.GA1521@caradoc.them.org> In-Reply-To: <20080716130755.GA1521@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807161723.18272.vladimir@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00189.txt.bz2 On Wednesday 16 July 2008 17:07:55 Daniel Jacobowitz wrote: > On Wed, Jul 16, 2008 at 04:52:24PM +0400, Vladimir Prus wrote: > > Does this happen in non-stop? Anyway, thread selections due to stop in all-stop > > mode all result in notification. > > Beats me. > > > > You'd get a notification there but only because we changed from thread > > > 1 to thread 2 inside the command. For the purposes of that command, > > > the "currently selected thread" is thread 1. > > > This is the command I don't think should get a notification: > > > > > > -thread-select 2 > > > -interpreter-exec --thread 1 console "thread 1" > > > > Why? Is it guaranteed that whenever CLI command is executed, the value to > > the 'thread' option is equal to whatever is current for UI? > > I'm totally lost with what you're trying to accomplish with these > notifications. > > Logically the CLI window offered by the GUI has a current thread. It may have. The most obvious design is that a given main window of an IDE has a current thread, and there's no separate current thread specific to CLI console widget. > The GUI selects it when a CLI command is run, either by -thread-select > or by -interpreter-exec --thread. No. GUI makes sure that the CLI command *entered by the user in CLI console* is executed in whatever thread is current, from user's point of view. Nothing prevents GUI to run CLI commands outside of CLI console, for whatever reasons. > If the CLI command changes that > thread, then the GUI needs to update its state from the notification. > If it doesn't change the thread, the GUI doesn't need to update. > > So what purpose is =thread-changed,thread-id="1" in the above example? The general purpose of "thread-selected" notification is to inform the frontend that the user wants a given thread to be selected in UI. Skipping such notification for -interpreter-exec --thread 1 console "thread 1" is OK only if we document that the "--thread" parameter should always be the selected UI thread, which seems a hard assumption. Say, a frontend might want to allow user-defined commands to be run on stop and send CLI commands on stop explicitly (either because breakpoint commands are not implemented in MI, or because frontend wants to run some commands no matter which breakpoint is hit). In non-stop mode, such commands presumably, will be run in the context of the thread that hit a breakpoint. But this thread is not necessary the thread that is selected in UI. I don't have a fully-baked example that will be broken by skipping the notification in this case; but I'm not confident such example will not arise. - Volodya