Re: [dsdp-dd-dev] DSF design question

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Monday 16 June 2008 20:08:57 Pawel Piech wrote:

> I have two follow-up questions.
> 
> 1. Do you consider this desirable to change the selected thread in UI when user types
> "thread XXX" in console? If we want main UI and console to have the same notion of
> the current thread, it seems the right thing to do.
> 
>   
>  I agree.
>  
> 2. Suppose the current thread selected in UI is thread 1. User types, in CLI console,
> "thread 2". The command is sent to GDB. We're in non-stop mode, and at this point,
> some other thread stops -- let's say thread 1. I presume DFS will try to get
> some information about this stopped thread -- let's assume it sends
> a single -stack-list-frames.
> 
>   - Assuming "thread 2" does not emit any notifications, will this cause DSF to
>   fail to emit -thread-select 1 before -stack-list-frames?
>   - Assuming "thread 2" does emit notifications about thread change, and DSF handles
>   such notification, is it guaranteed that the decision whether to send -thread-select
>   before -stack-list-frames is made only after "thread 2" is processed by GDB?
> 
> - Volodya
>   
>  Without GDB notifications, parsing CLI commands is the only solution I can think of.  
>  But with parsing only, this still leaves DSF-GDB broken wrt to user-defined commands as you pointed out above. 

>   
>  I have never used GDB from the command line, so my assumption that we could parse the 
>  CLI commands to detect thread switches may have been rather naive.  Your use case of user-defined commands 
>  is certainly one I haven't thought of.  A notification from GDB when the selected thread 
>  changes would help, although to use them DSF-GDB would have to add special handling of CLI commands
>  to force it to wait for this event before sending another command (either CLI or MI).

Okay, so the conclusion appears to be that it's best if GDB emit notifications when thread changes.
And if GDB does so, then DSF should be modified to avoid sending more commands to GDB until the
previous CLI command is done executing, and therefore all notification from it were processed. Right?

You point about multiple windows is a tricky one. If we have two windows, both in debug perspective,
and we type "thread 2" in GDB console in one window -- do we want to change selected thread in
UI in just one window? I think we do want it, and it requires just:

    - Making sure GDB emits the notification even if we're trying to select the same thread
    as already selected
    - Making sure the notification from gdb is associated back to the CLI command, and therefore
    to specific GDB console
    - Hooking that GDB console to DebugWindowContextService

Seems correct? 

BTW, which code path actually handles CLI commands. IIUC, GDB console is created auto-magically 
by ProcessConsoleManager whenever the GDB process is added to Launch. Where is DSF hooked into
that console?

- Volodya