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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Saturday 14 June 2008 15:00:20 Vladimir Prus wrote:

> 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?

- Volodya