Re: MI non-stop interface details

[Vladimir Prus <vladimir@codesourcery.com>]

On Friday 02 May 2008 21:59:14 Pawel Piech wrote:
> Vladimir Prus wrote:
> > On Friday 02 May 2008 21:31:08 Pawel Piech wrote:
> >
> >   
> >> 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.
> >>   
> >>  Thank You :-)  It would be more helpful if the thread-id field was 
> >>  left alone and always reported the triggering thread as it does now.  
> >>  It would be better (more consistent and logical) if the new field 
> >>  was used to indicate whether or not the whole container changed state.    
> >>     
> >
> > For avoidance of doubt, do you have any objections to *running using the "thread-id"
> > as the field name? Since this is new notification, there's no backward compatibility
> > issues, and there's no issue of which thread originally triggered anything.
> >
> > - Volodya
> >   
> First of all, I think it's important to make the events in all-stop and 
> non-stop mode to be consistent.  Additionally, it is helpful if the 
> fields, such as thread-id have consistent meaning even if they are used 
> in different events.  So for consistency sake it would be better to also 
> use thread-id to indicate the triggering thread in the running event as 
> well, and use a separate field to indicate whether the container changed 
> state.  BTW the triggering thread is needed in the running event, for 
> example when stepping in the all-stop mode.

And what the triggering thread would report in that case? The thread where
the step command was emitted? Frontend knows it already, no?

- Volodya