Re: MI threads behaviour

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

Marc Khouzam wrote:
>   
>> -----Original Message-----
>> From: Pawel Piech [mailto:pawel.piech@windriver.com]
>> Sent: Monday, July 14, 2008 11:56 AM
>> To: Marc Khouzam
>> Cc: Daniel Jacobowitz; Vladimir Prus; gdb@sources.redhat.com
>> Subject: Re: MI threads behaviour
>>
>>
>> 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.  
>>     
>
> With the example of two windows, can we block an MI command on window 2
> waiting for the CLI command to finish on window 1?
> I guess I didn't fully understand the example.
> Either way, I'm sure this solution if fine.
>
> Thanks
>
>   
Yes, so the blocking will have to be controlled at a low level based on 
the command type being sent.  What could prove to be more tricky is 
figuring out how to handle the possible flood of =thread-selected events 
for MI commands.  Two simple options would be to either just ignore this 
event while processing MI commands, or two use the --thread option to 
avoid the event all together.
Cheers,
Pawel

>> This is certainly 
>> inconvenient, but given the fact that it only applies to CLI 
>> commands, 
>> it should not have a performance impact.
>>
>> Cheers,
>> Pawel
>>
>>