Re: [patch:MI] Observer for thread-changed

[Vladimir Prus <ghost@cs.msu.su>]

On Tuesday 10 June 2008 06:03:46 Nick Roberts wrote:
>  > It all amounts to:
>  > 
>  >  - should there be an MI async event on -thread-select if the
>  >    reply already carries that information?
> 
> But the CLI command "thread" doesn't.  I think MI should try to reflect the
> state of GDB and the inferior.  It shouldn't really matter what commands were
> used to put it in that state.

We had this discussion in context of breakpoint notifications already, but I
think the thread notification makes those issues easier to discuss.

What is the purpose of the thread change notification? I think the purpose is
to enable the frontend to notice when the thread change, unexpectedly. For
example, due to "thread" CLI command or user-defined command that switches
threads, or due to an otherwise magical way. The frontend, most likely, should
react by marking the thread reported as selected by GDB also selected in GUI.

The question, then, if whether -thread-select should output this notification?
Suppose a frontend uses -thread-select to get some data in some thread without
making it selected. Then, if a notification is emitted, the frontend has to 
take special care not to mark the thread as selected in GUI.

As an aside, this is similar to notifications/signals in GUI libraries -- for
example, line edit control often has 'text changed' signal. If this signal is
emitted even when the text is changed programmatically, the application 
often has to specially prevent signals emitted as result of programmatic change
to be handled as if it was the user input.

So, I think that -thread-select *should not* emit thread-changed notification.
With the original version of your patch, it would be a one-line change, it's
probably a bit harder with the last version.

- Volodya