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]

RE: anynchronous vs. synchronous



> -----Original Message-----
> From: Vladimir Prus [mailto:ghost@cs.msu.su]
> Sent: Thursday, May 11, 2006 11:00 AM
> To: Alain Magloire
> Cc: gdb@sources.redhat.com
> Subject: Re: anynchronous vs. synchronous
> 
> On Thursday 11 May 2006 18:46, Alain Magloire wrote:
> 
> > > 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!
> >
> > You could tag all commands and when that separate receive thread parse
> the
> > answer it could put the answer to correct callback.  So in this case you
> > still could send command in batches.
> 
> Given that I specifically want to avoid callbacks, due to problems their
> cause, running debugger in separate thread *plus* using callbacks does not
> seem good idea. It seems like it's hard to have maintainable code-base
> (meaning no callbacks, everything synchronous), and good performance on
> slow
> links.
> 

Ok.

There is an implicit (I do not know if it is explicitly written in the
manual) guarantee that your commands will be treated in order of arrival, so
if for specific run commands i.e. next, cont, etc ...  you do not wait,
things should work fine, I'm assuming that the thread will process OOBs.  

The only problem that comes to mind is for graphic library with one UI
thread (Java/SWT, Java/Swing, etc ...) where the front-end will have to take
care not to issue commands in the UI thread where it can potentially freeze
the application, gdb can take to long to answer and in many cases do not
answer at all.

Another possibility, all action commands to have a default timeout to allow
the application to recuperate.



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