Re: MI non-stop interface details

[Vladimir Prus <vladimir@codesourcery.com>]

Pawel Piech wrote:

> Vladimir Prus wrote:
>> On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
>>   
>>> Pedro Alves wrote:
>>>     
>>>> I can't see how is it different -- in the frontend's perspective --
>>>> of keeping track of what to pass to --thread= *provided GDB doesn't switch
>>>> threads automatically*.  But then again, I'm no frontend writer.
>>>>   
>>>>       
>>> Using -thread-select makes it easier for the front end to be compatible
>>> with older versions of GDB.
>>>     
>>
>> Hmm, I though that only reason that -thread-select is simpler is because
>> in DSF, specifically, there's no central place where commands are send
>> and where --thread can be conveniently added. I'm not saying this is good,
>> or bad, but this is not the case for all frontend. Am I wrong?
>>
>> - Volodya
>>   
> In DSF-GDB there _is_ a central place where commands are sent, this is
> where the protocol state is adjusted using -thread-select.  However, the
> --thread option is being added to many but not all commands, so the same
> mechanism that adds the -thread-select could not be reused to add
> --thread option.  Instead each command which accepts --thread that would
> need to be adjusted to use the --thread, but only when in non-stop
> debugging mode.

This is not actually. The plan is for eery command will accept --thread.  
Those that don't have any use of it will ignore it. The only command,
at the moment, for which the meaning of --thread is not yet clear, and for
which the frontend might have to have custom decision logic, is --exec-continue.

- Volodya