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

[Pedro Alves <palves at redhat dot com>]

On 4/19/19 9:43 PM, Joel Brobecker wrote:
>>>   - patch #3 (master only): Tag the main thread, and silence
>>>     the thread-exit notification of the thread that got tagged.
>>>     Depending on the implementation, this patch would potentially
>>>     be acceptable for 8.3, but might need extra work to apply.
>>>     I think we've had enough problems with 8.3 as it is, I don't
>>>     want to add more things to do, so I vote OUT for 8.3.
>>
>> This doesn't seem right to me, given that the main thread may
>> legitimately exit before other threads.  If this approach is taken,
>> maybe tweak it a bit:
>>
>> silence the thread-exit notification of the thread that got tagged
>> _iff there are no other threads in the process_.
> 
> Wouldn't that be confusing? What would happen in that case is that
> we end up getting a a thread-exit notification with a thread ID
> for which there hasn't been a new-thread notification. Without
> knowing the implementation details of how GDB decides to silence
> or not thread notifications, people are going to ask themselves
> where the thread that exited came from, and why we didn't see
> a new-thread notification for it before.
> 
> To decide which approach we want to take - what would be the issue
> if we decided to silence the main thread's exit notification while
> some other threads might still be alive?

In my view, it's OK to not let the user know the main thread is
exiting when it's the last thread in the process because the process
is exiting right away.  But if the main thread is not the last
thread, then the process is going to stay around.  And in that case,
if a user wants thread exit notifications, I think it just makes sense
to let the user know a thread exited, more so since the main thread of
a program tends to be its most "important" thread.

I don't see the asymmetry (silent at creation, not silent at destruction)
in this particular case as surprising -- when the program is
starting up, there's only one thread, and I don't think users are
surprised to find that after running to main there's already one
thread in the thread list.

I also think that if we included the GDB thread id (and name) in thread creation/exited
notifications, similar to the output of inferior start/exit notifications, then users
would be even less surprised with the asymmetry, as users could clearly tell that
it's the main thread that is exiting:

Currently:

 [Thread 48192.0xd100 exited with code 1]

With gdb thread id and name:

[Thread 1.1 (48192.0xd100 "the thread's name") exited with code 1]

I think that would be a good overall change, regardless.

> Assuming Pedro is making
> a valid point, I think we should go back to pre-8.3 behavior, and
> show all thread create/exit notifications, including for the main
> thread.

Thanks,
Pedro Alves