This is the mail archive of the gdb-patches@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: Another proposal for frontends and queries.


 

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker
> Sent: Wednesday, September 16, 2009 5:41 PM
> To: Tom Tromey
> Cc: Marc Khouzam; gdb-patches@sourceware.org
> Subject: Re: Another proposal for frontends and queries.
> 
> > One idea from the user 'heinz' (sorry, I don't know your 
> real name!) was
> > to have a query in MI mode throw a specific error, then let 
> the front
> > end reissue the command with the correct response.

This is interesting.
Maybe there could even be a "^query" answer.
The tokenId could be used to label this new MI query.

One extra advantage is that an MI query will no longer block GDB.
Other MI commands could be accepted while leaving the queried
command "on hold".  With this, the frontend could choose to query
the user or not, without having GDB blocked during the operation.
I like this.

One worry I have is what will GDB do if the frontend does not answer
the query?  I guess it can leave the command in the "query queue" for
ever, probably won't hurt.

> this assumes
> that we don't perform any action if an error is thrown. Otherwise, the
> user sends the command, receives the query, cancels the command, and
> thinks nothing happen.

I believe this is what you meant Joel, but just to be sure:
for this to work, a query has to happen before any effect of the command
is applied.  If a command starts doing some work and then queries, then
GDB might be in an inconsistent state.  But this probably does not happen
with the existing queries... it sounds too dangerous.

> I've often let the best be the enemy of good, though.  It seems like
> an acceptable restriction in the way we implement commands, 
> particularly
> since it allows us to avoid potentially complex improvements of
> the command architecture.
> 
> That being said, for 7.0, we should just go with the easy and safe
> route.  That way, existing frontend can work with gdb-7.0, rather
> than having to update their code to handle the new approach.

Yes, in the case of Eclipse, we wouldn't be able to support this
until June 2010.

That would be nice addition to MI for a future release.  I'm looking
forward to making use of it.

Marc
 


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