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

[Vladimir Prus <ghost@cs.msu.su>]

On Sunday 15 June 2008 02:04:35 you wrote:
>  > > 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.
> 
> I agree.  I don't think that we should second guess what front ends will do.  

We should, or frontends will second guess what MI tells them. "Current thread"
is not a exact thing, and "current thread changed" is not an exact thing either,
so we should provide specific meaning that is most useful to frontends, and opposed
to providing a meaning that is most easy for gdb.

> I 
> think the role of MI is to provide a mechanism to report the state of GDB and 
> the inferior, not to provide a policy.  The front end developer can then filter
> out information that he doesn't need.  However he can't factor in information
> that GDB developers leave out because they consider it's not needed.

I'd say that gdb already provides sufficient information in response to -thread-select,
namely either ^done or ^error. Unless GDB has a bug, the output of ^done means that
the thread has changed.

- Volodya