Re: Another proposal for frontends and queries.

Tom Tromey
2009-09-17T19:52:39Z

>>>>> "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.

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.

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.

Tom