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

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Jun 14, 2008 at 07:09:37PM +0400, Vladimir Prus wrote:
> I'm afraid you are oversimplifying -- the "the notification is
> emitted whenever the active thread changes" is very nice, but it's very
> likely that every frontend author will not realize he has to ignore this
> notification from -thread-select. So, the documentation should either say
> that the notification is better ignored, or say that is not emitted. Now, what
> is better?

Seems clear to me: it should be in the example output of
-thread-select, and a reference to there from the description of the
event.

> I'd like this notification to communicate, from GDB to frontend, that GDB
> has encountered a command that indicates explicit user desire to change
> the thread he looks at, and that frontend typically should react by making
> that thread selected in UI. 

Wouldn't it make sense to use the same notification if the inferior
stopping causes the selected thread to change, which is how things
work today in all-stop?

> In other words, I argue for notification to be designed with the view of
> what frontend is supposed to do with it, not with what internal detail of
> GDB is been reported.

This is a good principle, but it's not right either.  Reporting the
internal state of GDB is bad design, but reporting based on what
frontends are supposed to do is also bad design: it assumes that you
can think of everything a frontend might want to do.  We need to
report logical interface events based on GDB's state.

-- 
Daniel Jacobowitz
CodeSourcery