From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9689 invoked by alias); 16 Jul 2008 13:33:41 -0000 Received: (qmail 9671 invoked by uid 22791); 16 Jul 2008 13:33:39 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 Jul 2008 13:33:19 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 41C12982C3; Wed, 16 Jul 2008 13:33:17 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id E14CC98200; Wed, 16 Jul 2008 13:33:16 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KJ788-0000qB-6q; Wed, 16 Jul 2008 09:33:16 -0400 Date: Wed, 16 Jul 2008 13:33:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI threads behaviour Message-ID: <20080716133316.GA3080@caradoc.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <200806181601.52404.vladimir@codesourcery.com> <200807161652.24626.vladimir@codesourcery.com> <20080716130755.GA1521@caradoc.them.org> <200807161723.18272.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807161723.18272.vladimir@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes 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/msg00190.txt.bz2 On Wed, Jul 16, 2008 at 05:23:17PM +0400, Vladimir Prus wrote: > > 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. I think you're assigning conflicting meanings to the same thing here. If "thread 1" means "select thread 1 in the UI", then doesn't the context of the command have to be whatever was previously selected in the UI? I don't think there's a need for breakpoint commands to be able to change the UI selection, and it would be very confusing since they could happen while the user was looking at something. Anyway, objection withdrawn; do whatever seems best to you. I can't follow this any more :-) -- Daniel Jacobowitz CodeSourcery