Re: asynchronous MI output commands

Re: asynchronous MI output commands

[Bjarke Viksoe]

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

bjarke
BVRDE - bvrde.sourceforge.net

Re: asynchronous MI output commands

[Daniel Jacobowitz]

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

Re: asynchronous MI output commands

[Bjarke Viksoe]

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

Re: asynchronous MI output commands

[Daniel Jacobowitz]

On Mon, May 08, 2006 at 12:50:03AM +0200, Bjarke Viksoe wrote:
> 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).

Well, that's a whole different problem.  Note that GDB is _not_ echoing
your commands here - it only handles output in MI mode.  The terminal
is doing it.  On Unix systems, you can solve this by running "stty
-echo" (beware, some shells reset this when in interactive mode - my
zsh was eating it, I had to try in bash).

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

How would changing the MI output improve this situation at all?  I
can't see it.

-- 
Daniel Jacobowitz
CodeSourcery

MI: anynchronous vs. synchronous

[Vladimir Prus]

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. 

I was thinking about this lately. From my experience, anynchronous
communication with gdb inside frontend can be rather inconvenient:

1. Instead of just:

      value = gdb.send_command("-data-evaluate-expression foo")["value"];

you need to use callbacks all over:

    gdb.addCommand("-data-evaluate-expression foo",
                   this,
                   &My_class::handleValue);

which increases the amount of code considerably, and makes following the
logic much harder.

2. The sequence of commands (where second command uses result of first)
becomes tricky to implement. Note only you'll need a callback method for
each command, but you can get undersired interaction with other commands:

     command_1
     some_unrelated_command_that_makes_result_of_command_1_invalid
     command_2_that_uses_no_invalud_result_of_command_1


Because of those issues, for a future version of KDevelop I plan to run
debugger in a separate thread, that can just block while waiting for reply
from gdb. So, there will be no callbacks at all, and the code will be
rather easy to understand, e.g:

   unsigned address = gdb.send_command("-data-evaluate-expression &i")
                                     ["value"].toInt();
   gdb.send_command(QString("-break-watch *%1").arg(address));

On the other hand, this will mean commands are sent one-by-one, so in your 
your 100ms round-trip case, this will be extremely slow. I still think that
given that 100ms links are very uncommon, that would be a right decision in
my case. But any ideas are welcome! 

- Volodya