RE: Another proposal for frontends and queries.

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com] 
> Sent: Thursday, September 17, 2009 3:52 PM
> To: Marc Khouzam
> Cc: 'Joel Brobecker'; 'gdb-patches@sourceware.org'
> Subject: Re: Another proposal for frontends and queries.
> 
> >>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:
> 
> Marc> This is interesting.
> Marc> Maybe there could even be a "^query" answer.
> Marc> The tokenId could be used to label this new MI query.
> 
> Marc> One extra advantage is that an MI query will no longer 
> block GDB.
> Marc> Other MI commands could be accepted while leaving the queried
> Marc> command "on hold".  With this, the frontend could 
> choose to query
> Marc> the user or not, without having GDB blocked during the 
> operation.
> Marc> I like this.
> 
> Marc> One worry I have is what will GDB do if the frontend 
> does not answer
> Marc> the query?  I guess it can leave the command in the 
> "query queue" for
> Marc> ever, probably won't hurt.
> 
> I think we are talking about different approaches.
> 
> Having a query "on hold" implies, to me, either a change to use
> continuation passing style, or that GDB will reenter the 
> event loop from
> query().
> 
> Either of these is certainly doable, but my experience with these
> approaches (in GUI and CORBA contexts) has been fairly negative.
> 
> Perhaps I misunderstood what you are saying, though.

Nope, you got it right.  But now I see that was not the proposal.

> Instead this idea is to have query() issue a particular kind 
> of error --
> and abort the command.
> 
> Then the MI user could recognize this error, send a special command to
> stuff some answers into a queue that query() would read, and then
> restart the command from scratch.

Ok, now I see.  I didn't realize the command would be restarted from scratch.
Thanks for the explanation.  And that is a better solution.  Although I a bit
concerned about an infinite loop between the FE and GDB, if things are not
handled properly by the FE.

> There are two assumptions underlying this idea:
> 
> 1. A command will always ask the same queries in the same order.
> 2. A command won't commit some change before a query.
> 
> #1 can be relaxed a little bit, if needed, by having each query report
> its identity.  Then the query queue would actually be a map, 
> associating
> an identity with an answer.
> 
> #2 seems like a reasonable assumption.
> 
> With this approach, GDB would not keep any state when a query fails.
> It would not need to.

This makes sense.

The last (I think :-)) part that I don't understand is if a FE must
code in advance for a potential query?  This solution seems to go
towards a way that would allow a FE to be ready for any query
on any command.  A new query could be added to a command by a new GDB
version, and FEs would not need to change.  That would be nice.  
Is that how you see it?
I'm asking because, in some case a FE
will want to answer the query itself, without seeking input from the user.
For example, for PRecord, when the query asks if we should allow to change
memory, I won't ask the user, I just want to say 'y'.
I don't see how a FE could be smart enough to generically answer
queries like that? (unless we code for it in advance)

On the flip side, if a FE knows in advance the potential queries
to a specific command, then maybe all we need is some new MI general
parameter "-query <y | n>" that could be added by the frontend
to any command (some details would need to be worked out to handle
multiple queries in the same command though).

Does this make sense?

Thanks

Marc