> >
> >If I were writing a front-end, I would have an arbitration layer which
> >sent questions to GDB and received answers. The answers will come back
> >one at a time, in the same order the questions were asked. If you send
> >two -var-evaluate-expression commands, you'll get back two answers, in
> >that same order.
> >
> >Am I missing something? Is there a reason that this isn't enough?
> ...
>
>
> Because of the latency, my "abstraction layer" runs in its own thread.
This
> makes the UI wonderfully responsive, but doesn?t allow a component/view
to
> submit a command and read the answer in the same context. Answers arrive
> out of context and are processed separately - creating a high need to
know
> what the answer originated from.
Sorry, but I don't feel like you've answered my question. Why does
this interfere with pipelining?
Thread A:
- gdb_thread.submit_question("-var-evaluate-expression A")
Thread B:
- gdb_thread.submit_question("-var-evaluate-expression B")
GDB thread:
- Send "-var-evaluate-expression A". Record this as an outstanding
request.
- Send "-var-evaluate-expression B". Record this as an outstanding
request.
- Notice that data is available.
- Parse it, and notice that it is a response to a command. Take the
first command off the queue of outstanding requests. See that it
is -var-evaluate-expression A. Return the answer to that request's
submission object, in whatever way you need to.
- Notice that more data is available... etc.
If this isn't workable, can you fill in the piece I'm missing? Why
not? Each command should generate a single synchronous (^done, ^error)
response.