Re: MI non-stop interface details

[Pawel Piech <pawel.piech@windriver.com>]

Vladimir Prus wrote:
> 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? 
Right.
> Frontend knows it already, no?
>
> - Volodya
>   
Right, it typically does... unless the command was issued through the 
CLI console, in which case the UI has to do some work to get it.  But as 
long as GDB has the information, it's simpler and more reliable to get 
it from the event.

-Pawel