Re: [PATCH v2 13/25] Always process target events in the main UI

[Pedro Alves <palves at redhat dot com>]

On 03/22/2016 10:26 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> This makes target events always be always processed with the main UI
>> as current UI.  This way, warnings, debug output, etc. are always
>> consistently sent to the main console.
> 
> Anything wrong if we don't do so?  In patch 08, current_ui is switched
> to right ui if something is typed in from that ui, isn't good to process
> events in that ui as well?  say, I type some commands in one ui, and I
> expect the output go to my ui rather than the main one.

The problem is that there's no connection at all between an asynchronous
target event and "that" command that you mention.  There may even not
be a command at all.  E.g., say do you do "continue&" in UI 2, and then
the program spawns threads, etc.  And then you type something in
UI 3 (current UI is now 3), for example, switch to another inferior "run &"
it.  Consider that UI 4 may be the MI channel, and the frontend
sends MI commands meanwhile as well, thus switching the current UI too.
All the while, some random thread hits some internal event that happens
to trigger some warning deep down inside symbol reading or some such.
Where should the warning go?  What if an internal error triggers?  Where
should we present the query?  Or any other query, for the matter?
Since it's indeterminate which is the best UI channel, best is to
define it as defaulting to the main console.

A similar issue happens with where e.g., "set debug infrun 1" output goes.
If we don't force-default to the main UI, then output for random asynchronous
events ends up going to whatever UI gdb internally happened to last switch
to, which is an internal implementation detail.  (Usually it'll be the last
UI you typed in).  Again in this case, I think we need to default to
the main console/UI, and then come up with something specialized for
debug output.  Currently we do:

 if (debug_foo)
   fprintf_unfiltered (gdb_stdlog, ...);

 if (debug_bar)
   fprintf_unfiltered (gdb_stdlog, ...);

which sends output to the current UI's gdb_stdlog.  But we may
want to say that "debug_foo" goes to UI 1, and "debug_bar" goes
to UI 2.  For example, because "set debug foo 1" was activated
in UI 1, and "set debug bar" was activated in UI 2.  This suggests
reworking the debug APIs to have one stream object per debug setting,
I think.  Obviously, I'd rather not do this as requirement for this
series.

Thanks,
Pedro Alves