Re: [PATCH 2/2] doc: Improve documentation about MI thread output

[Simon Marchi <simon dot marchi at ericsson dot com>]

On 17-04-12 03:33 PM, Eli Zaretskii wrote:
>> From: Simon Marchi <simon.marchi@ericsson.com>
>> Date: Wed, 12 Apr 2017 15:26:08 -0400
>>
>>>> +there is a selected thread and no @var{thread-id} argument was passed to the
>>>
>>> How can there not be a selected thread?
>>
>> When the currently selected inferior is not running.  The obvious case is the initial
>> state of gdb.  But it's also possible to have threads but none is selected, for example
>> when you add a second inferior and switch to it, while the first inferior is running.
>>
>> The field is output if inferior_ptid != null_ptid, so maybe there are other situations
>> I am not aware of where there isn't a current thread.
> 
> I think we need to describe at least the most "popular" situations
> where this happens.  The initial state of GDB is not an interesting
> case, but others are.  In particular, IMO it would be good to state
> that when there's only one inferior being debugged that has been run
> already, there will always be a selected thread.

I agree that we could give an example of situation where there _isn't_
a selected thread.  Readers may, like you did, find that it's an odd
claim and wonder how it's possible that there isn't a selected thread.
But I don't think it's useful (and maybe even counterproductive) to try
to define some situation where the field will always be present.

The important thing that users of this API need to know is that the field
may not be there.  This will encourage them to program defensively and check
whether the field is present before trying to use it.  If we try to define a
green zone where the field is supposedly always be present, it will incite some
people to skip the check, which will potentially come back and bite them if the
behavior of GDB changes or there's a situation we haven't thought of where it
can happen.

Simon