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

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

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

I guess I didn't answer your first question right.  From what I see,
you are right that Sequence does not give atomicity.  But it is the class we
use to execute multiple commands in sequence (just not atomically.)
I guess I jumped the gun on your question when I read

> By that, I mean that the each next command can be only constructed when
> the output of the previous one is known, 

which is fulfilled by Sequence.

> and we don't want any other
> command to be executed until the sequence is fully done?

This part of your question, I missed.
I'm not sure if there is a way to do that.  But my DSF knowledge is far
from complete.

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

I didn't know you were setting me up for a non-stop use case :-)
We haven't changed DSF to support non-stop yet.  We are actually working on it
right now, so your questions are helpful.

Every time a command is queued in AbstractMIControl.queueCommand, it comes
with information indicating for which thread it is meant for.  So, I believe
that if we changed the GDB current thread as your use case requires, we would
automatically issue a new -thread-select to change the thread back, before
sending the next GDB command that is being queued (if necessary.)
The important thing here is that GDB does not change its current thread on
its own, which I believe you are taking care of for non-stop mode.

I guess my previous answer was wrong again :-)
The GDB current thread is in fact reset, and it this is done by the same 
mechanism that changed it in the first place.

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

This is a valid point.  We didn't discuss the console with non-stop yet...

We would have to apply the thread-select solution above to console commands.
Maybe we already do, actually.  I'm not sure, but I'll check.

Such a solution would still work with older versions of GDB, so we would not
have to if/else that code, which will prove pretty clean.  In fact, I can probably
make the changes now, without having to wait for the new version of GDB.

Make sense?

Marc