From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28883 invoked by alias); 16 Jul 2008 13:08:17 -0000 Received: (qmail 28875 invoked by uid 22791); 16 Jul 2008 13:08:17 -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:07:57 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 03852982C3; Wed, 16 Jul 2008 13:07:56 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id C7FFB98200; Wed, 16 Jul 2008 13:07:55 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KJ6jb-0000Ov-8K; Wed, 16 Jul 2008 09:07:55 -0400 Date: Wed, 16 Jul 2008 13:08:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI threads behaviour Message-ID: <20080716130755.GA1521@caradoc.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <200806181601.52404.vladimir@codesourcery.com> <200807161551.01112.vladimir@codesourcery.com> <20080716121045.GA30641@caradoc.them.org> <200807161652.24626.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807161652.24626.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/msg00188.txt.bz2 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. The GUI selects it when a CLI command is run, either by -thread-select or by -interpreter-exec --thread. 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? -- Daniel Jacobowitz CodeSourcery