Re: asynchronous MI output commands

[Daniel Jacobowitz <drow at false dot org>]

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