Re: MI threads behaviour

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jul 16, 2008 at 05:23:17PM +0400, Vladimir Prus wrote:
> > 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?
> 
> The general purpose of "thread-selected" notification is to inform the
> frontend that the user wants a given thread to be selected in UI.
> Skipping such notification for 
> 
>    -interpreter-exec --thread 1 console "thread 1"
> 
> is OK only if we document that the "--thread" parameter should always be
> the selected UI thread, which seems a hard assumption. Say, a frontend
> might want to allow user-defined commands to be run on stop and send CLI
> commands on stop explicitly (either because breakpoint commands are not
> implemented in MI, or because frontend wants to run some commands no
> matter which breakpoint is hit). In non-stop mode, such commands presumably,
> will be run in the context of the thread that hit a breakpoint. But this
> thread is not necessary the thread that is selected in UI. I don't have
> a fully-baked example that will be broken by skipping the notification in
> this case; but I'm not confident such example will not arise.

I think you're assigning conflicting meanings to the same thing here.
If "thread 1" means "select thread 1 in the UI", then doesn't the
context of the command have to be whatever was previously selected in
the UI?  I don't think there's a need for breakpoint commands to be
able to change the UI selection, and it would be very confusing since
they could happen while the user was looking at something.

Anyway, objection withdrawn; do whatever seems best to you.  I can't
follow this any more :-)

-- 
Daniel Jacobowitz
CodeSourcery