This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI threads behaviour
On Wednesday 16 July 2008 17:07:55 Daniel Jacobowitz wrote:
> 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.
It may have. The most obvious design is that a given main window
of an IDE has a current thread, and there's no separate current thread
specific to CLI console widget.
> The GUI selects it when a CLI command is run, either by -thread-select
> or by -interpreter-exec --thread.
No. GUI makes sure that the CLI command *entered by the user in CLI console*
is executed in whatever thread is current, from user's point of view. Nothing
prevents GUI to run CLI commands outside of CLI console, for whatever reasons.
> 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.
- Volodya