This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: asynchronous MI output commands
- From: Daniel Jacobowitz <drow at false dot org>
- To: Bjarke Viksoe <bviksoe at hotmail dot com>
- Cc: gdb at sourceware dot org
- Date: Sun, 7 May 2006 18:01:45 -0400
- Subject: Re: asynchronous MI output commands
- References: <BAY111-F52DA19D048441A185E919A0AB0@phx.gbl>
On Sun, May 07, 2006 at 11:40:54PM +0200, Bjarke Viksoe wrote:
> >Daniel Jacobowitz wrote:
> >
> >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?
>
> No, the abstraction layer is exactly my design - but as I explained: the
> goal of my tool is that it's used over a remote line (eg. SSH over
> internet) where the answer can be a couple of 100ms delayed. It is most
> desirable to be able to send multiple commands and have the front-end
> digest the answer as they slowly arrive - updating the UI in increments.
> Yes, my views need to send multiple -var-evaluate-expression and this is
> the reason that I'm forced to restrict the design to what you describe. The
> reason it's not good enough: it so slow.
>
> 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.
--
Daniel Jacobowitz
CodeSourcery