Re: [PATCH master+7.12 v2 2/3] Emit inferior, thread and frame selection events to all UIs

Pedro Alves
2016-09-16T18:26:00Z

On 09/15/2016 05:20 PM, Simon Marchi wrote:
> On 16-09-14 02:30 PM, Pedro Alves wrote:
>> We could solve that by adding the thread group id (inferior id) to
>> the notification, I think:
>>
>> =thread-selected,id="3",thread-group="i1",frame="..."
>>
>> =thread-selected,id="0",thread-group="i2",frame="..."
>>
>> ...
>>

> That sounds good. I think we can plan this for 7.13 though, the goal now is
> to get the basic use cases working, while not breaking any previous ones.

OK.

>> But, I suspect that we end up suppressing this case:
>>
>> (gdb) define thread-foo
>>> thread $arg0
>>> end
>> (gdb) thread-foo 2
>>
>> Contrived, but certainly not hard to imagine user-commands doing
>> something useful along with changing the selected thread.
>>
>> What happens in this case?
>
> I think that's actually the opposite. The purpose of this whole ugly condition
> is to avoid sending a second event, if we removed that whole part with strcmp's,
> we would end up sending events twice. It would not be nice, but it would not be
> as bad as not sending any event.

Ah!

> That big condition is clearly unclear though :). I suggest breaking it in its own
> function, where it will be more readable (even though not technically better):

Indeed, that'd be a great boon.

>
> And then the condition becomes readable, and we understand the intent:
>
>
> /* If the command already reports the thread change, no need to do it
> again. */
> && !command_sends_thread_selected_event (command))
> ...

Awesome!

>
>
> To address you uneasiness with -thread-select, let's see how that that code interacts
> with that command. First, an event about the thread change is sent in
> mi_cmd_thread_select. Then, command_sends_thread_selected_event will return true,
> making us skip sending the event again.
>
> WDYT?

I like it.

Thanks,
Pedro Alves