Re: MI threads behaviour

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jul 16, 2008 at 04:52:24PM +0400, Vladimir Prus wrote:
> Does this happen in non-stop? Anyway, thread selections due to stop in all-stop
> mode all result in notification.

Beats me.

> > You'd get a notification there but only because we changed from thread
> > 1 to thread 2 inside the command.  For the purposes of that command,
> > the "currently selected thread" is thread 1.
> > This is the command I don't think should get a notification:
> > 
> >   -thread-select 2
> >   -interpreter-exec --thread 1 console "thread 1"
> 
> Why? Is it guaranteed that whenever CLI command is executed, the value to
> the 'thread' option is equal to whatever is current for UI? 

I'm totally lost with what you're trying to accomplish with these
notifications.

Logically the CLI window offered by the GUI has a current thread.
The GUI selects it when a CLI command is run, either by -thread-select
or by -interpreter-exec --thread.  If the CLI command changes that
thread, then the GUI needs to update its state from the notification.
If it doesn't change the thread, the GUI doesn't need to update.

So what purpose is =thread-changed,thread-id="1" in the above example?

-- 
Daniel Jacobowitz
CodeSourcery