Re: [PATCH v3] [RFC] Fix AIX thread exit events not being reported and UI to show kernel thread ID.

[John Baldwin <jhb@FreeBSD.org>]

On 5/2/24 9:30 AM, Ulrich Weigand wrote:
> Aditya Vidyadhar Kamath <akamath996@gmail.com> wrote:
> 
>> +  /* Describes the number of thread exit events reported.  */
>> +  std::unordered_set<pthdb_pthread_t> exited_threads;
>> +
>> +  /* Describes if thread is still in queue and not in unknown state.  */
>> +  std::vector<pthdb_pthread_t> in_queue_threads;
> 
> I don't really like these new global variables.  exited_threads
> seems to be only ever added to, so it will just keep growing
> forever?  in_queue_threads seems to be fully local to the
> sync_threadlists routine, so why is it not just a local
> variable there?

I think exited_threads is not global but per-inferior?

in_queue_threads does indeed seem to be something that could be local
to the function.

> As a more general question, I'm wondering why you're completely
> changing the way sync_threadlists works.  I think the overall
> idea of sync_threadslists, i.e. to compare the thread list of
> the OS with GDB's thread list and then update the latter to
> match the former, is still valid.  I thought you'd simply change
> the way the "pbuf" list is generated to filter out those threads
> that the OS considers in terminated state.

I think in this case it's a bit different as the internal list from
pbuf "grows forever" (specifically, exited threads do not get removed
from the thread library's internal list it seems, just remain forever
as an exited thread).  In that case, you don't have to extract two
thread lists so that you can walk the union of the two lists looking
for mismatches.  Instead, the pbuf list will always be a superset of
GDB's list, so it is sufficient to walk the pbuf list and decide how
to handle each thread.  (I must say that I'm surprised by the behavior
of exited threads staying in AIX's thread library list forever, but
it does seem to be the case.)

-- 
John Baldwin