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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Sunday 04 May 2008 15:33:03 Marc Khouzam wrote:

> > 2. Is there a mechanism to atomically execute a sequence of commands?
> > By that, I mean that the each next command can be only constructed when
> > the output of the previous one is known, and we don't want any other
> > command to be executed until the sequence is fully done?
> 
> org.eclipse.dd.dsf.concurrent.Sequence.java
> You can see an example of it in
> org.eclipse.dd.gdb.internal.provisional.launching.ServicesLaunchSequence.java

I'm afraid I still don't see where it ensures atomicity. In executeStep,
we call next step's execute method, with a RequestMonitor, and when request
monitor's handleCompleted is called, we execute next step.
What will prevent some other code to send a gdb command between the
calls to 'execute' of the next step and the call to rm's 'handleCompleted'?

> > 3. AbstractMIControl.queueCommand will send -thread-select as necessary.
> > Is there any place where the GDB current thread is reset to what it
> > was before the command is executed?
> 
> I don't think so.
> 
> > If not, it seems that the current thread
> > seen by the user in the GDB console will potentially be different from what
> > is shown in the UI.
> 
> -thread-select will also change the thread for the GDB console, so the console
> and the UI should remain consistent, no?

Yes, but assume this use case. GDB is in non-stop mode, and user is looking at
thread X. In the meantime, thread Y is also stopped. It is probably desirable
to get some information about thread Y, for example the stack, to also show it
to the user. At the same time, it's probably not desirable to change the
current thread to Y. After all, there's already stopped thread X and user
is looking at its data. So, it's best to get the stack frames for Y without
changing the current thread either in UI or in GDB. I think not changing the current
thread in UI is easy, but without code to restore thread back, the current 
thread in GDB will change.

There's another issue -- I think we don't want to allow the user to emit any GDB
commands in the console while the current thread is temporary changed -- which
brings us back to the question how atomic sequences are implemented.

- Volodya