Re: =frame-selected MI notification

[nickrob at snap dot net dot nz (Nick Roberts)]

 > I'll review this patch later, but I wanted to clarify this point. The current
 > codebase emits =thread-selected already, and it does not use observers,
 > by design. The reason is that MI frontend is not actually interested in
 > changes in GDB's current thread. 

I think Emacs, and other frontends that have a console, will always be
interested in the current thread/selected frame.  The behaviour of CLI
commands like up, down, print etc depend on it.

Of course, if GDB emits a notification then the frontend can always choose to
ignore it.  If GDB doesn't emit a notification then the frontend has to send
an extra command to get the information it needs after after every user
command.

It's not only thread and frame changes that could be emitted as notifications.
Setting, deleting, disabling breakpoints with CLI commands could also emit
notifications.  This would save having to send -break-list after every user
command.

 > ...
 > Furthermore, I do not think that observers for either thread or frame
 > changes is good idea, design wise. The fact that gdb has current thread
 > or current frame at the code level, is, IMNSHO, a design bug. Global
 > variables are generally bad, and those two are certainly not exception.
 > It's better not to make situation worse by adding new mechanism based
 > on that design bug.

I think it would be hard to write a large C program with no global variables
but, in any case, the concept of current thread/selected frame seems to be a
great convenience when using GDB from the command line.

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