Re: MI threads behaviour

Pawel Piech
2008-07-14T20:27:16Z

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
>>
>>