This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

MI: anynchronous vs. synchronous


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

 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]