Re: asynchronous MI output commands

["Bjarke Viksoe" <bviksoe@hotmail.com>]

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

Right. When I was testing all this I ran into more trouble. I would actually 
see something like this:

(gdb) -var-evaluate-expression A
^done,value="12-var-evaluate-expression A
34"
(gdb)
^done,value="1234"

...because of the lack of flow-control in the telnet/SSH session (notice how 
the next command is embedded in the output of the first). This put me back 
to square#1 since there was now no 1:1 relationship between cmd/answ. While 
I agree that your plan is workable, I just concluded that keeping track of a 
command-list wasn't a reliable option without some severe pain when recovery 
was needed (aka back to the <token> option) - and I didn't feel that I was 
getting any closer to having a state-less component.

I would expect that some front-ends (GUI based ones) will employ a similar 
design as mine - even if they are in an environment more attached to their 
GDB - since we've already seen that fireing a backtrace-type command for 
every step can be very slow and would block the UI unreasonably if not 
batched in a thread other than the main GUI one.
My take was that I assumed that the output was more detailed simply because 
it would make my life easier in handling the returned output - instead of 
having to build complex schemes just to call a simple GDB command.

bjarke