MI threads behaviour

MI threads behaviour

[Vladimir Prus]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]


Here's the promised document about how I'd like threads to work in MI. It's not
fully implemented at this point, but I'd like to have some discussion before we
go on further. Anybody sees anything wrong or suboptimal about this proprosed
behaviour?

- Volodya


[-- Attachment #2: mi-threads.txt --]
[-- Type: text/plain, Size: 5110 bytes --]


Threads management in GDB
=========================

CLI interface
=============

In CLI mode, GDB maintains the current thread and current frame -- which
are specified by the user, with commands like 'thread', 'frame' and 'up/down'.
Most of the operation, such as printing variable values, work in context of
the current thread/frame. In all-stop mode, GDB will also implicitly switch
current thread/frame to the thread that has stopped. In non-stop mode, GDB
never automatically switches the thread.

It is possible that the current thread exits.  In non-stop mode, GDB will
automatically reset the 'current thread' to an invalid value. Essentially
no commands are allowed after that, and user must switch to some still-alive
thread. In all-stop mode, GDB does not allow commands until it stops, and it does
not stop on thread exit. So, if a thread exits, GDB continues to execute the
program until an event in some other thread happens -- in which case it
switches to that other thread automatically. In
all-stop/sync/scheduler-locking-on mode the user will have to use Ctrl-C after
the current thread exits to stop some other thread.

MI interface
============

In MI mode, there are two current threads -- the current thread as shown in
UI, and the current thread from GDB point of view.  The frontend should either
avoid relying on GDB current thread, or make sure to switch GDB current
thread as necessary. Also, we expect the frontend to notice when user requests
a change in current thread via a CLI command such as 'thread', or a
user-defined command, and update the UI current thread. There are two
possible approaches:
 
1. The recommended way is to use the --thread option for all MI
commands, and this makes the GDB current thread almost irrelevant.

GDB will have a new notification, =thread-selected, which is used to
report to the frontend that during processing of the last MI command,
GDB discovered user's request to change current thread to something.
Internally, this will be implemented by checking of the GDB current
thread has changed when we're done with processing MI command.
In all-stop mode, the notification will be emitted when any thread stops.
    
The CLI behaviour of setting GDB current thread to invalid value if the
current thread exits will be preserved, but is of limited value, since 
the frontend does not depend on current thread directly, and will be notified
about thread exit anyway. Therefore, no notification will be emitted in
this case.

The notification will be emitted even if the thread user requested to be
selected is the same as currently selected thread. Imagine the frontend
has two windows open -- in one, UI has thread 1 selected, and in another,
UI has thread 2 selected. If user types "thread 2" in GDB console in the
first window, would expect the first window UI to switch to thread 2. So,
the notification should be emitted even if GDB current thread is 2, 
already.

To summarize:
   - With --thread option, frontend should not care at all about GDB's
   current thread.  There's no need to ever send -thread-select
   - GDB will emit =thread-changed, and =frame-changes notification, which
   should be interpred as saying "I think that user wants, via CLI, 
   to switch to this thread/frame"

2. The frontends not willing to upgrade to use the --thread option may use
-thread-select prior the sending the actual MI command, and optionally
-thread-select after the command.

In this case, the frontend should, in addition to maintaining current thread
as in UI, also remember which thread is current in GDB, and whenever sending 
a command that should be executed in a thread different from the current GDB
thread, switch GDB to the desired thread. In particular, if sending several
commands at once, one of which can be CLI command, the frontend should be
prepared for the CLI command to change current thread. Frontend should never
ever send a command to GDB's pipe if it previously sent a CLI command and
haven't yet got its output back.

The =thread-selected notification, in this case, should be interpreted to
mean:
   (1) User's request that the selected thread be changed, and
   (2) Notification that GDB current thread has changed
The (2) trait does not matter if --thread is used, but in this case the
frontend need to use this information to figure if -thread-select should be
sent.

Note that conceptually, the --thread option is equivalent to -thread-select,
followed by the command, followed by -thread-select back to the original
thread (unless the command been executed changes thread itself), followed by
-stack-select-frame for old fram. The --thread option is allowed whenever
the -thread-select command is.

Threads and non-stop
====================

To simplify initial implementation, we allow *all* MI commands even if
inferiour is running. Furthermore, we don't care if the command tries to 
work on a running thread. If the command requires that the thread be stopped,
it will error out, eventually. We don't try to pick a stopped thread and
execute the command there. For now, let's decide it's frontend problem.

Re: MI threads behaviour

[Vladimir Prus]

On Wednesday 18 June 2008 16:01:52 you wrote:
> 
> Here's the promised document about how I'd like threads to work in MI. It's not
> fully implemented at this point, but I'd like to have some discussion before we
> go on further. Anybody sees anything wrong or suboptimal about this proprosed
> behaviour?

Anybody is still planning to have some comments? If not, the described behaviour
will be implemented as soon as non-stop patches are in, and I'll work on converting
the posted text into docs.

- Volodya

Re: MI threads behaviour

[Daniel Jacobowitz]

On Wed, Jun 18, 2008 at 04:01:52PM +0400, Vladimir Prus wrote:
> The CLI behaviour of setting GDB current thread to invalid value if the
> current thread exits will be preserved, but is of limited value, since 
> the frontend does not depend on current thread directly, and will be notified
> about thread exit anyway. Therefore, no notification will be emitted in
> this case.

What about in all-stop mode, where the CLI behavior is to change to a
new event thread?

> The notification will be emitted even if the thread user requested to be
> selected is the same as currently selected thread. Imagine the frontend
> has two windows open -- in one, UI has thread 1 selected, and in another,
> UI has thread 2 selected. If user types "thread 2" in GDB console in the
> first window, would expect the first window UI to switch to thread 2. So,
> the notification should be emitted even if GDB current thread is 2, 
> already.

I don't understand the need for this.  If you're going to let the user
type a CLI command, then before you can do that you have to make sure
GDB and the UI are synchronized on the current thread/frame.
Otherwise "backtrace" or "thread" won't work.

-- 
Daniel Jacobowitz
CodeSourcery

RE: MI threads behaviour

[Marc Khouzam]

Hi,

> Threads management in GDB
> =========================
> 
> CLI interface
> =============
> 
> In CLI mode, GDB maintains the current thread and current frame -- which
> are specified by the user, with commands like 'thread', 'frame' and 'up/down'.
> Most of the operation, such as printing variable values, work in context of
> the current thread/frame. In all-stop mode, GDB will also implicitly switch
> current thread/frame to the thread that has stopped. In non-stop mode, GDB
> never automatically switches the thread.
> 
> It is possible that the current thread exits.  In non-stop mode, GDB will
> automatically reset the 'current thread' to an invalid value. Essentially
> no commands are allowed after that, and user must switch to some still-alive
> thread. In all-stop mode, GDB does not allow commands until it stops, and it
> does not stop on thread exit. So, if a thread exits, GDB continues to execute 
> the program until an event in some other thread happens -- in which case it
> switches to that other thread automatically. In
> all-stop/sync/scheduler-locking-on mode the user will have to use Ctrl-C after
> the current thread exits to stop some other thread.

I'm not familiar with scheduler-locking-on, so I'm not sure if it is relevant
to my question, but I believe that in all-stop, one can use Ctrl-C to force
GDB to stop; if the thread that was executing has exited, and the user then
uses Ctrl-C, what thread will GDB point to when it stops?

 
> MI interface
> ============
> 
> In MI mode, there are two current threads -- the current thread as shown in
> UI, and the current thread from GDB point of view.  The frontend should either
> avoid relying on GDB current thread, or make sure to switch GDB current
> thread as necessary. Also, we expect the frontend to notice when user requests
> a change in current thread via a CLI command such as 'thread', or a
> user-defined command, and update the UI current thread. There are two
> possible approaches:
>  
> 1. The recommended way is to use the --thread option for all MI
> commands, and this makes the GDB current thread almost irrelevant.
> 
> GDB will have a new notification, =thread-selected, which is used to
> report to the frontend that during processing of the last MI command,
> GDB discovered user's request to change current thread to something.
> Internally, this will be implemented by checking of the GDB current
> thread has changed when we're done with processing MI command.
> In all-stop mode, the notification will be emitted when any thread stops.
>     
> The CLI behaviour of setting GDB current thread to invalid value if the
> current thread exits will be preserved, but is of limited value, since 
> the frontend does not depend on current thread directly, and will be notified
> about thread exit anyway. Therefore, no notification will be emitted in
> this case.
> 
> The notification will be emitted even if the thread user requested to be
> selected is the same as currently selected thread. Imagine the frontend
> has two windows open -- in one, UI has thread 1 selected, and in another,
> UI has thread 2 selected. If user types "thread 2" in GDB console in the
> first window, would expect the first window UI to switch to thread 2. So,
> the notification should be emitted even if GDB current thread is 2, 
> already.
> 
> To summarize:
>    - With --thread option, frontend should not care at all about GDB's
>    current thread.  There's no need to ever send -thread-select
>    - GDB will emit =thread-changed, and =frame-changes notification, which
>    should be interpred as saying "I think that user wants, via CLI, 
>    to switch to this thread/frame"

=thread-changed or =thread-selected?  Not a big deal, but I think
=thread-selected is better since:
"The notification will be emitted even if the thread user requested to be
selected is the same as currently selected thread"

 
> 2. The frontends not willing to upgrade to use the --thread option may use
> -thread-select prior the sending the actual MI command, and optionally
> -thread-select after the command.
> 
> In this case, the frontend should, in addition to maintaining current thread
> as in UI, also remember which thread is current in GDB, and whenever sending 
> a command that should be executed in a thread different from the current GDB
> thread, switch GDB to the desired thread. In particular, if sending several
> commands at once, one of which can be CLI command, the frontend should be
> prepared for the CLI command to change current thread. Frontend should never
> ever send a command to GDB's pipe if it previously sent a CLI command and
> haven't yet got its output back.

Is it the output of the CLI command that should be used to know the current
thread has changed?  Or is it the  =thread-selected notification of (2) below?

> The =thread-selected notification, in this case, should be interpreted to
> mean:
>    (1) User's request that the selected thread be changed, and
>    (2) Notification that GDB current thread has changed
> The (2) trait does not matter if --thread is used, but in this case the
> frontend need to use this information to figure if -thread-select should be
> sent.

Here, I believe there is a race condition.  In the example you give above with
two windows, one window could send a CLI command changing the thread, but
the second window may send an MI command, before receiving the
=thread-selected notification and will act on the wrong thread.
I don't see how we could fix this.
Or maybe I misunderstood your explanation?

      
> Note that conceptually, the --thread option is equivalent to -thread-select,
> followed by the command, followed by -thread-select back to the original
> thread (unless the command been executed changes thread itself), followed by
> -stack-select-frame for old fram. The --thread option is allowed whenever
> the -thread-select command is.
> 
> Threads and non-stop
> ====================
> 
> To simplify initial implementation, we allow *all* MI commands even if
> inferiour is running. Furthermore, we don't care if the command tries to 
> work on a running thread. If the command requires that the thread be stopped,
> it will error out, eventually. We don't try to pick a stopped thread and
> execute the command there. For now, let's decide it's frontend problem.

Looks good overall.

thanks

marc

Re: MI threads behaviour

[Pawel Piech]

Marc Khouzam wrote:
>> The =thread-selected notification, in this case, should be interpreted to
>> mean:
>>    (1) User's request that the selected thread be changed, and
>>    (2) Notification that GDB current thread has changed
>> The (2) trait does not matter if --thread is used, but in this case the
>> frontend need to use this information to figure if -thread-select should be
>> sent.
>>     
>
> Here, I believe there is a race condition.  In the example you give above with
> two windows, one window could send a CLI command changing the thread, but
> the second window may send an MI command, before receiving the
> =thread-selected notification and will act on the wrong thread.
> I don't see how we could fix this.
> Or maybe I misunderstood your explanation?
>   
Hi Marc,
I seem to remember that we talked about the fact that there is a race 
condition and decided that it is unavoidable.  Our proposed workaround 
was to force the client to wait for the result of each CLI command 
before issuing another CLI or MI command.  This is certainly 
inconvenient, but given the fact that it only applies to CLI commands, 
it should not have a performance impact.

Cheers,
Pawel

RE: MI threads behaviour

[Marc Khouzam]

> -----Original Message-----
> From: Pawel Piech [mailto:pawel.piech@windriver.com]
> Sent: Monday, July 14, 2008 11:56 AM
> To: Marc Khouzam
> Cc: Daniel Jacobowitz; Vladimir Prus; gdb@sources.redhat.com
> Subject: Re: MI threads behaviour
> 
> 
> Marc Khouzam wrote:
> >> The =thread-selected notification, in this case, should be 
> interpreted to
> >> mean:
> >>    (1) User's request that the selected thread be changed, and
> >>    (2) Notification that GDB current thread has changed
> >> The (2) trait does not matter if --thread is used, but in 
> this case the
> >> frontend need to use this information to figure if 
> -thread-select should be
> >> sent.
> >>     
> >
> > Here, I believe there is a race condition.  In the example 
> you give above with
> > two windows, one window could send a CLI command changing 
> the thread, but
> > the second window may send an MI command, before receiving the
> > =thread-selected notification and will act on the wrong thread.
> > I don't see how we could fix this.
> > Or maybe I misunderstood your explanation?
> >   
> Hi Marc,
> I seem to remember that we talked about the fact that there is a race 
> condition and decided that it is unavoidable.  Our proposed 
> workaround 
> was to force the client to wait for the result of each CLI command 
> before issuing another CLI or MI command.  

With the example of two windows, can we block an MI command on window 2
waiting for the CLI command to finish on window 1?
I guess I didn't fully understand the example.
Either way, I'm sure this solution if fine.

Thanks

> This is certainly 
> inconvenient, but given the fact that it only applies to CLI 
> commands, 
> it should not have a performance impact.
> 
> Cheers,
> Pawel
> 

Re: MI threads behaviour

[Pawel Piech]

Marc Khouzam wrote:
>   
>> -----Original Message-----
>> From: Pawel Piech [mailto:pawel.piech@windriver.com]
>> Sent: Monday, July 14, 2008 11:56 AM
>> To: Marc Khouzam
>> Cc: Daniel Jacobowitz; Vladimir Prus; gdb@sources.redhat.com
>> Subject: Re: MI threads behaviour
>>
>>
>> Marc Khouzam wrote:
>>     
>>>> The =thread-selected notification, in this case, should be 
>>>>         
>> interpreted to
>>     
>>>> mean:
>>>>    (1) User's request that the selected thread be changed, and
>>>>    (2) Notification that GDB current thread has changed
>>>> The (2) trait does not matter if --thread is used, but in 
>>>>         
>> this case the
>>     
>>>> frontend need to use this information to figure if 
>>>>         
>> -thread-select should be
>>     
>>>> sent.
>>>>     
>>>>         
>>> Here, I believe there is a race condition.  In the example 
>>>       
>> you give above with
>>     
>>> two windows, one window could send a CLI command changing 
>>>       
>> the thread, but
>>     
>>> the second window may send an MI command, before receiving the
>>> =thread-selected notification and will act on the wrong thread.
>>> I don't see how we could fix this.
>>> Or maybe I misunderstood your explanation?
>>>   
>>>       
>> Hi Marc,
>> I seem to remember that we talked about the fact that there is a race 
>> condition and decided that it is unavoidable.  Our proposed 
>> workaround 
>> was to force the client to wait for the result of each CLI command 
>> before issuing another CLI or MI command.  
>>     
>
> With the example of two windows, can we block an MI command on window 2
> waiting for the CLI command to finish on window 1?
> I guess I didn't fully understand the example.
> Either way, I'm sure this solution if fine.
>
> Thanks
>
>   
Yes, so the blocking will have to be controlled at a low level based on 
the command type being sent.  What could prove to be more tricky is 
figuring out how to handle the possible flood of =thread-selected events 
for MI commands.  Two simple options would be to either just ignore this 
event while processing MI commands, or two use the --thread option to 
avoid the event all together.
Cheers,
Pawel

>> This is certainly 
>> inconvenient, but given the fact that it only applies to CLI 
>> commands, 
>> it should not have a performance impact.
>>
>> Cheers,
>> Pawel
>>
>>     

Re: MI threads behaviour

[Vladimir Prus]

On Thursday 10 July 2008 01:03:11 Daniel Jacobowitz wrote:
> On Wed, Jun 18, 2008 at 04:01:52PM +0400, Vladimir Prus wrote:
> > The CLI behaviour of setting GDB current thread to invalid value if the
> > current thread exits will be preserved, but is of limited value, since 
> > the frontend does not depend on current thread directly, and will be notified
> > about thread exit anyway. Therefore, no notification will be emitted in
> > this case.
> 
> What about in all-stop mode, where the CLI behavior is to change to a
> new event thread?

We're talking about thread exit here -- does CLI automatically switch to a non-dead
thread when the current one exits? If so, then the notification would have to
be emitted, too.

> 
> > The notification will be emitted even if the thread user requested to be
> > selected is the same as currently selected thread. Imagine the frontend
> > has two windows open -- in one, UI has thread 1 selected, and in another,
> > UI has thread 2 selected. If user types "thread 2" in GDB console in the
> > first window, would expect the first window UI to switch to thread 2. So,
> > the notification should be emitted even if GDB current thread is 2, 
> > already.
> 
> I don't understand the need for this.  If you're going to let the user
> type a CLI command, then before you can do that you have to make sure
> GDB and the UI are synchronized on the current thread/frame.
> Otherwise "backtrace" or "thread" won't work.

What is "synchronized"? You don't need to emit -thread-select, since there's
--thread, and what I mean is that if have a window where UI's selected thread
is 1, and you type "thread 2" in console, and frontend sends

   -interpreter-exec --thread 1 "thread 2"

then one should get

   =thread-selected,id="2"

regardless of what inferior_ptid was immediately before this command is processed.

- Volodya


 

Re: MI threads behaviour

[Daniel Jacobowitz]

On Wed, Jul 16, 2008 at 03:51:00PM +0400, Vladimir Prus wrote:
> On Thursday 10 July 2008 01:03:11 Daniel Jacobowitz wrote:
> > On Wed, Jun 18, 2008 at 04:01:52PM +0400, Vladimir Prus wrote:
> > > The CLI behaviour of setting GDB current thread to invalid value if the
> > > current thread exits will be preserved, but is of limited value, since 
> > > the frontend does not depend on current thread directly, and will be notified
> > > about thread exit anyway. Therefore, no notification will be emitted in
> > > this case.
> > 
> > What about in all-stop mode, where the CLI behavior is to change to a
> > new event thread?
> 
> We're talking about thread exit here -- does CLI automatically switch to a non-dead
> thread when the current one exits? If so, then the notification would have to
> be emitted, too.

It doesn't do anything when the thread exits - it's blocked in wait.
But at the next stop it will select the event thread.

> > > The notification will be emitted even if the thread user requested to be
> > > selected is the same as currently selected thread. Imagine the frontend
> > > has two windows open -- in one, UI has thread 1 selected, and in another,
> > > UI has thread 2 selected. If user types "thread 2" in GDB console in the
> > > first window, would expect the first window UI to switch to thread 2. So,
> > > the notification should be emitted even if GDB current thread is 2, 
> > > already.
> > 
> > I don't understand the need for this.  If you're going to let the user
> > type a CLI command, then before you can do that you have to make sure
> > GDB and the UI are synchronized on the current thread/frame.
> > Otherwise "backtrace" or "thread" won't work.
> 
> What is "synchronized"? You don't need to emit -thread-select, since there's
> --thread, and what I mean is that if have a window where UI's selected thread
> is 1, and you type "thread 2" in console, and frontend sends
> 
>    -interpreter-exec --thread 1 "thread 2"
> 
> then one should get
> 
>    =thread-selected,id="2"
> 
> regardless of what inferior_ptid was immediately before this command is processed.

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"

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI threads behaviour

[Vladimir Prus]

On Wednesday 16 July 2008 16:10:45 Daniel Jacobowitz wrote:
> On Wed, Jul 16, 2008 at 03:51:00PM +0400, Vladimir Prus wrote:
> > On Thursday 10 July 2008 01:03:11 Daniel Jacobowitz wrote:
> > > On Wed, Jun 18, 2008 at 04:01:52PM +0400, Vladimir Prus wrote:
> > > > The CLI behaviour of setting GDB current thread to invalid value if the
> > > > current thread exits will be preserved, but is of limited value, since 
> > > > the frontend does not depend on current thread directly, and will be notified
> > > > about thread exit anyway. Therefore, no notification will be emitted in
> > > > this case.
> > > 
> > > What about in all-stop mode, where the CLI behavior is to change to a
> > > new event thread?
> > 
> > We're talking about thread exit here -- does CLI automatically switch to a non-dead
> > thread when the current one exits? If so, then the notification would have to
> > be emitted, too.
> 
> It doesn't do anything when the thread exits - it's blocked in wait.
> But at the next stop it will select the event thread.

Does this happen in non-stop? Anyway, thread selections due to stop in all-stop
mode all result in notification.

> > > > The notification will be emitted even if the thread user requested to be
> > > > selected is the same as currently selected thread. Imagine the frontend
> > > > has two windows open -- in one, UI has thread 1 selected, and in another,
> > > > UI has thread 2 selected. If user types "thread 2" in GDB console in the
> > > > first window, would expect the first window UI to switch to thread 2. So,
> > > > the notification should be emitted even if GDB current thread is 2, 
> > > > already.
> > > 
> > > I don't understand the need for this.  If you're going to let the user
> > > type a CLI command, then before you can do that you have to make sure
> > > GDB and the UI are synchronized on the current thread/frame.
> > > Otherwise "backtrace" or "thread" won't work.
> > 
> > What is "synchronized"? You don't need to emit -thread-select, since there's
> > --thread, and what I mean is that if have a window where UI's selected thread
> > is 1, and you type "thread 2" in console, and frontend sends
> > 
> >    -interpreter-exec --thread 1 "thread 2"
> > 
> > then one should get
> > 
> >    =thread-selected,id="2"
> > 
> > regardless of what inferior_ptid was immediately before this command is processed.
> 
> 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? 

- Volodya

Re: MI threads behaviour

[Daniel Jacobowitz]

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

Re: MI threads behaviour

[Vladimir Prus]

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

Re: MI threads behaviour

[Daniel Jacobowitz]

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