Re: [RFA 2/2][master only] gdb/windows-nat.c: Get rid of main_thread_id global

[André Pönitz <apoenitz at t-online dot de>]

On Mon, Apr 22, 2019 at 06:28:55PM +0100, Pedro Alves wrote:
> On 4/22/19 4:23 PM, André Pönitz wrote:
> > On Mon, Apr 22, 2019 at 03:24:46PM +0100, Pedro Alves wrote:
> >> I don't see the asymmetry (silent at creation, not silent at destruction)
> >> in this particular case as surprising [...]
> > 
> > It's not surprising, but it's inconsistent 
> > and causes extra work in
> > cases one wants to mechanically examine such output.
> 
> I'm curious about what extra work you're thinking of.

As far as I understand it, any (non-MI) user wanting to keep track of
running threads would need to find out which events are "not surprising"
(for which version of GDB...) and mentally (or in code) "generate"
the "missing" events. That's a kind of "work". 

> Can't think of anything significant.

It's not significant, but less surprising to me personally, i.e.
violating the principle of least astonishment.
 
> But do note that this discussion does not affect MI.

I understand that, and for thread related notifications MI is sufficient
for my frontend purposes, but in general MI does not cover all functionality
of CLI and already this discrepancy is a surprise to some degree. I'd
rather see the differences go away over time, not to increase.

> So what do you propose?  My proposal kept these two ideas in mind:
> 
> - be quiet wrt to threads with single-threaded programs.

TBH, I don't see the necessity of this requirement. That would be two
lines of noise per run. 

> - inform the user the main thread exited while other threads stay running.

Also here, I don't see enough gain in one suppressed line of output
to compensate for the inconsistency, this time even with a CLI user hat on.

Andre'