From: Vladimir Prus <ghost@cs.msu.su>
To: gdb@sources.redhat.com
Subject: MI: anynchronous vs. synchronous
Date: Thu, 11 May 2006 10:31:00 -0000 [thread overview]
Message-ID: <e3uuaa$ueq$1@sea.gmane.org> (raw)
In-Reply-To: <BAY111-F52DA19D048441A185E919A0AB0@phx.gbl>
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
prev parent reply other threads:[~2006-05-11 8:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-07 22:30 asynchronous MI output commands Bjarke Viksoe
2006-05-07 22:50 ` Daniel Jacobowitz
2006-05-08 0:36 ` Bjarke Viksoe
2006-05-08 1:52 ` Daniel Jacobowitz
2006-05-11 10:31 ` Vladimir Prus [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='e3uuaa$ueq$1@sea.gmane.org' \
--to=ghost@cs.msu.su \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox