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

["Marc Khouzam" <marc.khouzam@xxxxxxxxxxxx>]

> 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?
> 
> To clarify further, it appears that if -stack-list-frames is passed to
> AbstractMIControl.queueCommand when fRxCommands.size() < 3, that command will
> be send to GDB without making sure that "thread 2" is done, and by the time notifications
> from "thread 2" arrive, "-stack-list-frames" is already in pipe and cannot be undone.
> Am I missing some safeguard?

Yes, I believe you are right.
Our console integration is not very robust right now.
The CDT seems to parse console commands to make sure any changes
are reflected internally.  I'm not sure if it does that for "thread"
but DSF could do the same.  
We would simply pay attention to "thread" console commands, and update 
our currentThread accordingly.  We currently have that code
for breakpoints and watchpoints.

I think we are going to have take the time to properly test the integration
of the console with the UI in DSF at some point in the near future.

So, not much help from me, except to agree that there is a problem currently.

Marc