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

[Pedro Alves <palves at redhat dot com>]

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