Re: [patch:MI] Observer for thread-changed

[Nick Roberts <nickrob@snap.net.nz>]

 > >  > 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".
 > 
 > You probably missed those. Here's what my checkout of gdb.texinfo reads:
 > 
 > 	@item =thread-created,id="@var{id}"
 > 	@itemx =thread-exited,id="@var{id}"
 > 	A thread either was created, or has exited.  The @var{id} field
 > 	contains the @value{GDBN} identifier of the thread.

OK.  Are there any tests?

I think that event notifications should have their own node.  I also think that
the manual should be restructured so that the node "GDB/MI Output Records"
comes _under_ the node "GDB/MI Command Syntax" and that the nodes in "GDB/MI
Output Records" are linked with their description in "GDB/MI Output Syntax"


 > > You could say the same about user-defined functions that use the "threads"
 > > command.

 > No, because user-defined functions are typed by the user and passed through
 > to GDB, and if those commands change thread, UI should update. On the
 > contrary, if the frontend sent -thread-select, it means it wanted to set GDB
 > current thread to be the same as the current thread presently shown in the
 > UI, so I see no point for frontend to be notified. Can you outline a use case
 > where frontend would actually like to be notified about the thing it just
 > did?

In my scenario the frontend would automatically display the selected thread,
not select the thread that is displayed.


 > > I don't think MI should be used as a programming language.  I don't think
 > > -thread-select should be used by the front end except when the user
 > > explicitly requests to change threads.  In fact, I would even suggest that
 > > there should be no -thread-select and that all MI commands should be
 > > reflective

 > What is "reflective"?

Maybe it's not the right word.  Perhaps I mean introspective, i.e., just
reports the state like -break-list or -environment-pwd and doesn't change it
like -thread-select or -stack-select-frame, for example.

 
> > With a complete set of notifications, the usual CLI commands could be used
 > > to change state and the front end could just parse the MI output.

 > Could be used where? If in GDB console, then sure, but that does not require
 > that -thread-select output notification.

I mean the front end could just use CLI commands to change the state provided
there were MI notifications that would report that change.


 > > But the first patch was wrong for other reasons, as Pedro pointed out.

 > IIUC, the primary objection was that we'd emit notification even if
 > gdb_thread_select caught an exception. Can we protect against this by
 > checking that inferior_ptid actually changed?

Pedro says he has a patch that splits the notion of user/frontend selected
thread and frame, from the internally selected thread and frame.  Let's wait
to see how that fits in.


-- 
Nick                                           http://www.inet.net.nz/~nickrob