From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Nick Roberts <nickrob@snap.net.nz>, ghost@cs.msu.su
Subject: Re: [patch:MI] Observer for thread-changed
Date: Tue, 10 Jun 2008 01:40:00 -0000 [thread overview]
Message-ID: <200806100104.28694.pedro@codesourcery.com> (raw)
In-Reply-To: <18509.45981.233865.890248@kahikatea.snap.net.nz>
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:
> > > annotate_thread_changed ();
> > > gdb_thread_select (uiout, tidstr, NULL);
> > > + observer_notify_thread_changed ();
> > > }
> >
> > 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 first
> 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.
--
Pedro Alves
next prev parent reply other threads:[~2008-06-10 0:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-09 12:16 Nick Roberts
2008-06-09 13:36 ` Pedro Alves
2008-06-09 13:28 ` Pedro Alves
2008-06-09 15:06 ` Pedro Alves
2008-06-09 14:15 ` Pedro Alves
2008-06-09 23:35 ` Nick Roberts
2008-06-10 1:40 ` Pedro Alves [this message]
2008-06-10 2:30 ` Nick Roberts
2008-06-10 3:13 ` Pedro Alves
2008-06-10 6:39 ` Nick Roberts
2009-01-17 0:10 ` [PATCH]:annotations [was Re: [patch:MI] Observer for thread-changed] Nick Roberts
2009-01-17 17:54 ` [PATCH]:annotations Tom Tromey
2008-06-10 8:26 ` [patch:MI] Observer for thread-changed Vladimir Prus
2008-06-10 9:24 ` Nick Roberts
2008-06-10 10:26 ` Vladimir Prus
2008-06-10 17:23 ` Daniel Jacobowitz
2008-06-14 18:52 ` Vladimir Prus
2008-06-14 19:13 ` Tom Tromey
2008-06-14 19:22 ` Bob Rossi
2008-06-15 3:20 ` Nick Roberts
2008-06-14 20:04 ` Vladimir Prus
2008-06-15 21:51 ` Tom Tromey
2008-06-14 19:43 ` Daniel Jacobowitz
2008-06-15 0:44 ` Nick Roberts
2008-06-15 21:03 ` Vladimir Prus
2008-06-15 22:31 ` Nick Roberts
2008-06-16 22:28 ` Daniel Jacobowitz
2008-06-15 17:58 ` Vladimir Prus
2008-06-10 8:40 ` Vladimir Prus
2008-06-10 9:19 ` Nick Roberts
2008-06-10 9:36 ` Vladimir Prus
2008-06-11 0:08 ` Nick Roberts
2008-06-11 7:46 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200806100104.28694.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=ghost@cs.msu.su \
--cc=nickrob@snap.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox