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

[Vladimir Prus <ghost at cs dot msu dot su>]

On Tuesday 10 June 2008 12:39:49 you wrote:
>  > 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.
> 
> You could say the same about user-defined functions that use the "threads"
> command.

No, because user-defined functions are typed by the user and passed through to
GDB, and if those commands change thread, UI should update. On the contrary,
if the frontend sent -thread-select, it means it wanted to set GDB current
thread to be the same as the current thread presently shown in the UI, so
I see no point for frontend to be notified. Can you outline a use case where
frontend would actually like to be notified about the thing it just did?

> I don't think MI should be used as a programming language.  I don't think
> -thread-select should be used by the front end except when the user explicitly
> requests to change threads.  In fact, I would even suggest that there should be
> no -thread-select and that all MI commands should be reflective

What is "reflective"?

> and not change 
> the state of GDB or the inferior.  

Even though the patch that adds --thread option to all MI commands is almost ready,
I'd expect some frontends not to update for a while, and IIUC, Eclipse DSF is not
actually willing to update at all. So, frontends will be using -thread-select
for all purposes.

> With a complete set of notifications, 
> the usual CLI commands could be used to change state and the front end could
> just parse the MI output.

Could be used where? If in GDB console, then sure, but that does not require
that -thread-select output notification.

>  > 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.
> 
> But the first patch was wrong for other reasons, as Pedro pointed out.

IIUC, the primary objection was that we'd emit notification even if
gdb_thread_select caught an exception. Can we protect against this by
checking that inferior_ptid actually changed?

- Volodya