From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4396 invoked by alias); 10 Jun 2008 00:04:49 -0000 Received: (qmail 4388 invoked by uid 22791); 10 Jun 2008 00:04:49 -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; Tue, 10 Jun 2008 00:04:31 +0000 Received: (qmail 4701 invoked from network); 10 Jun 2008 00:04:29 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jun 2008 00:04:29 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch:MI] Observer for thread-changed Date: Tue, 10 Jun 2008 01:40:00 -0000 User-Agent: KMail/1.9.9 Cc: Nick Roberts , ghost@cs.msu.su References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806091428.29157.pedro@codesourcery.com> <18509.45981.233865.890248@kahikatea.snap.net.nz> In-Reply-To: <18509.45981.233865.890248@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200806100104.28694.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2008-06/txt/msg00181.txt.bz2 A Monday 09 June 2008 23:50:05, Nick Roberts wrote: > Pedro Alves writes: > > Sorry, if I missed the discussion on it, but, > > > > A Monday 09 June 2008 13:16:09, Nick Roberts wrote: > > > =A0 =A0annotate_thread_changed (); > > > =A0 =A0gdb_thread_select (uiout, tidstr, NULL); > > > + =A0observer_notify_thread_changed (); > > > =A0} > > > > This is conceptually not right. gdb_thread_select is a libgdb > > function, that filters exceptions. If do_captured_thread_select > > throws an error, you will still call the observer. Plus, > > do_captured_thread_select is already printing the thread change > > to MI, which means you'll get the output twice now, in MI? > > I don't think that's a problem. Removing the output from -thread-select > would make it backwardly incompatible. > > Why not call the observer from inside do_captured_thread_select, > > instead of on both CLI and MI commands? > > Yes, you're right. Presumably I could also put it in a clause in > gdb_thread_select? I did have it in do_captured_thread_select in the fir= st > patch but I moved it. I can't fully explain why now but I think I must > have got confused by output of the frame_changed observer, which was also > part of that patch, being triggered by "info threads". > Right, and this happens due to the overload GDB makes on internally selected thread/frame, and user selected thread/frame. More on that Real Soon Now (TM)... Stay tuned. > > Also, it may make sense to add a "reason" parameter to > > the observer, as in "changed due to user/frontend request", or > > "due to a stop event", but that's not actually required right now. > > I'm not sure what use this information would be. If it's due to a stop > event then the reason should be given in the async output. It all amounts to: - should there be an MI async event on -thread-select if the reply already carries that information? - if a command requires a synchronous reply, then it should be implemented in the command itself, not in an observer. > How about the change below instead? This, of course, requires no change = to > mi-main.c. I'd really prefer to keep gdb_thread_select just an exception wrapper, and do the observer call in do_captured_thread_select. --=20 Pedro Alves