From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch:MI] Observer for thread-changed
Date: Tue, 10 Jun 2008 09:19:00 -0000 [thread overview]
Message-ID: <18510.14942.143700.410083@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200806101057.19272.ghost@cs.msu.su>
> > Index: infrun.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/infrun.c,v
> > retrieving revision 1.278
> > diff -p -u -p -r1.278 infrun.c
> > --- infrun.c 6 Jun 2008 00:33:52 -0000 1.278
> > +++ infrun.c 9 Jun 2008 12:13:25 -0000
> > @@ -3605,6 +3605,7 @@ normal_stop (void)
> > target_terminal_ours_for_output ();
> > printf_filtered (_("[Switching to %s]\n"),
> > target_pid_to_str (inferior_ptid));
> > + observer_notify_thread_changed ();
> > annotate_thread_changed ();
> > previous_inferior_ptid = inferior_ptid;
> > }
>
> Pedro's has asked if we'd want to call the observer only when we've
> selected a frame in the new thread. Have you decided if that's a good
> idea or not?
My observer doesn't use the selected frame, so I don't have an opinion.
> > ...
> > +static void
> > +mi_thread_changed ()
> > +{
> > + struct mi_interp *mi = top_level_interpreter_data ();
> > + struct interp *interp_to_use;
> > + struct ui_out *old_uiout, *temp_uiout;
> > + int version;
> > +
> > + fprintf_unfiltered (mi->event_channel, "thread-changed");
> > + interp_to_use = top_level_interpreter ();
> > + old_uiout = uiout;
> > + temp_uiout = interp_ui_out (interp_to_use);
> > + version = mi_version (temp_uiout);
> > + temp_uiout = mi_out_new (version);
> > + uiout = temp_uiout;
> > + ui_out_field_int (uiout, "new-thread-id", pid_to_thread_id (inferior_ptid));
> > + mi_out_put (uiout, mi->event_channel);
> > + uiout = old_uiout;
> > + gdb_flush (mi->event_channel);
> > +}
>
> Since your other patches have similar code, how about introducing a helper
> function for creating temporary uiout, as part of this patch?
Refactoring requires pointers to functions and function arguments and makes the
code harder to read. I am happy to do this when there is more than one such
function.
> > @@ -241,6 +242,7 @@ mi_cmd_thread_select (char *command, cha
> > error ("mi_cmd_thread_select: USAGE: threadnum.");
> >
> > rc = gdb_thread_select (uiout, argv[0], &mi_error_message);
> > + observer_notify_thread_changed ();
>
> As I've explained in the other email, I think that thread-changed
> notification should not be emitted for -thread-select, since the frontend
> does not need notification about something it just explicitly did
> itself. So, this call probably should disappear.
When Emacs migrates fully to MI I anticipate it would just process the
the notification and ignore the direct output from -thread-select. That would
mean that -thread-select and the CLI "thread" command are processed the same
way.
> OK with the above changes.
>
> Are you planning to write tests, and document the new notification?
There certainly should be tests and documentation, and I will do write some,
but I don't see any for the existing notifications, namely "thread-created" and
"thread-exited".
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2008-06-10 8:26 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
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 [this message]
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=18510.14942.143700.410083@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=gdb-patches@sources.redhat.com \
--cc=ghost@cs.msu.su \
/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