Re: [PATCH] Don't send queries to the MI interpreter

[Pedro Alves <palves@redhat.com>]

On 02/10/2017 05:12 PM, Pedro Alves wrote:

> I've run into these queries deep down in the record layer
> in the past, and wondered about getting rid of them.
> 
> Particularly this one:
> 
> 	  if (!yquery (_("Do you want to auto delete previous execution "
> 			"log entries when record/replay buffer becomes "
> 			"full (record full stop-at-limit)?")))
> 	    error (_("Process record: stopped by user."));
> 
> In order to query, the inferior is already temporarily stopped.
> So why not just unconditionally error, and lets user tweak
> "set record stop-at-limit" and continue if they want.

Let me expand on this a bit.

I have a local unfinished branch somewhere that attempts to address
the "pagination/queries in the primary CLI prevent MI async
notifications (like *stopped) on the secondary MI channel" issue.
I think there's a PR about it, but I can't find it now.  It's the
one that led to Eclipse disabling pagination.

The issue is that pagination is handled by starting a new nested
event loop deep inside the print that triggered the pagination,
and while a secondary event loop is running, no target events
are processed at all (see gdb_readline_wrapper, the
target_async(0) call).  So GDB will only notice that the inferior
stopped for a trap when the pagination/query is unblocked.

So the idea to address this was to continue processing target
events in the background and send them to MI, even while the
CLI is stopped in the pagination.  Meanwhile, if some target event
ends up producing _more_ output _while_ the CLI is already
waiting for the user to request another page of output, we'd need
to buffer the output somewhere temporarily, in order
to later dump it on the screen when whatever we were
outputting that paginated is fully flushed/output.

This suggested actually always buffering asynchronous output
and dumping it on the screen at a safe point.  I.e., output
generated inside handle_inferior_event would always go to
a buffer, and then dumped on the screen after processing the event,
when safe.

And it is at this point that I thought that it is odd to
query and ask for user input deep down inside the record layer,
while handling some asynchronous execution event -- i.e.,
deep down inside handle_inferior_event.  If we're buffering
output, when the user won't see the query anyway.
Hmm, now that I think of it, the "Do you want to auto delete
previous execution" query wouldn't be converted to an error,
but instead to a something like TARGET_WAITKIND_NO_HISTORY,
I suppose.

OK, I found the branch.  Pushed here now:

  https://github.com/palves/gdb/commits/palves/console-pagination

Thanks,
Pedro Alves