Re: MI non-stop interface details

[Vladimir Prus <vladimir@codesourcery.com>]

On Friday 02 May 2008 20:58:24 Pawel Piech wrote:

> > If the thread-id field has a value of "all", then all threads are stopped,
> > but it's just a shortcut for a number of *stopped, one per each thread.
> >   
> This leaves out an important piece of information: the triggering 
> thread, 

Ah, I mostly had *running in mind, that does not have any triggering thread.

> which is used by the IDE to decide which thread should get the  
> focus.  You may not see a use case for it now, but sooner or later you 
> will add an option to the breakpoint to stop all threads in non-stop 
> mode and you'll want to tell the client which thread hit the breakpoint.

Right now, *stopped reports the thread which hit the breakpoint. In
all-stop mode, all threads are stopped. In non-stop mode, only that thread
is stopped.

We surely can add an extra field to indicate which threads are actually stopped,
if this makes life easier.

> >> I see no reason to create a separate name space and in fact adding 
> >> another name space just requires more logic to maintain it.  thread-id 
> >> is just a handle that is obtained through well-documented commands, the 
> >> MI clients are not likely to get confused by the fact that containers 
> >> and threads are in the same namespace.  Additionally, if GDB was ever to 
> >> support more hierarchical systems: such as 
> >> target->core->processes->threads, it will have to keep revising the 
> >> protocol (in incompatibility inducing ways) to keep up.  But I guess 
> >> you'd have to believe that this is a real issue first.
> >>     
> >
> > I think the MI commands to query the hierarchy of "containers" will be fairly
> > agnostic of the actual meaning of each containers (just like variable objects
> > allow to describe arbitrary structure). That said, I'm not 100% that
> > making the namespace of containers and namespace of thread IDs is not going
> > to upset existing frontends.
> >   
> > - Volodya
> >   
> Can you think of a scenario in a client which would break?  Would  
> KDevelop break?  

I cannot create a concrete use-case where a client will break, yet.

> Maybe implementers of other client can speak up on this.  

If they read this list :-(

- Volodya