Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-dd-dev] DSF design question

> Hello,
> I was looking at the DSF source code and have some questions about the
> overall design:

Pawel is the best to answer such questions, but I'll give it a shot.

> 1. What is the purpose of DsfExecutor interface? It seem to be supposed to
> make sure that some things are executed in a single thread, but:
> - What things are those, exactly

The Services must run within the Executor.  Services are, for example,
the ExpressionService which provides information about variables and
expressions, the BreakPoint service, etc.

> - Why executing them in a single thread is necessary
> For example, looking at AbstractMIControl.processMIOutput, I see that
> quite a number of DfsRunnables are passed to the executor. What problem
> does that solve?

It was mostly to avoid having to deal with the complexity of multi-threading
(no need for semaphores/synchronization).

You can find detailed documentation at:
The White Paper explains this in detail (within the White paper, see
DSF White Paper->Concurrency Model, and then DSF Concurrency Model)

> 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?
You can see an example of it in

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

Feel free to send more questions.


Back to the top