Re: MI threads behaviour

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

Marc Khouzam wrote:
>> The =thread-selected notification, in this case, should be interpreted to
>> mean:
>>    (1) User's request that the selected thread be changed, and
>>    (2) Notification that GDB current thread has changed
>> The (2) trait does not matter if --thread is used, but in this case the
>> frontend need to use this information to figure if -thread-select should be
>> sent.
>>     
>
> Here, I believe there is a race condition.  In the example you give above with
> two windows, one window could send a CLI command changing the thread, but
> the second window may send an MI command, before receiving the
> =thread-selected notification and will act on the wrong thread.
> I don't see how we could fix this.
> Or maybe I misunderstood your explanation?
>   
Hi Marc,
I seem to remember that we talked about the fact that there is a race 
condition and decided that it is unavoidable.  Our proposed workaround 
was to force the client to wait for the result of each CLI command 
before issuing another CLI or MI command.  This is certainly 
inconvenient, but given the fact that it only applies to CLI commands, 
it should not have a performance impact.

Cheers,
Pawel