Re: [PATCH] gdb/py-inferior: Keep inferior threads in a map

[Lancelot SIX <Lancelot.Six@amd.com>]

On 08/11/2022 21:44, Simon Marchi wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> On 11/7/22 13:47, Lancelot SIX via Gdb-patches wrote:
>> diff --git a/gdb/python/py-inferior.c b/gdb/python/py-inferior.c
>> index 8847a6d9308..9fd5f30fcdb 100644
>> --- a/gdb/python/py-inferior.c
>> +++ b/gdb/python/py-inferior.c
>> @@ -30,17 +30,9 @@
>>   #include "gdbsupport/gdb_signals.h"
>>   #include "py-event.h"
>>   #include "py-stopevent.h"
>> +#include <map>
>>
>> -struct threadlist_entry
>> -{
>> -  threadlist_entry (gdbpy_ref<thread_object> &&ref)
>> -    : thread_obj (std::move (ref))
>> -  {
>> -  }
>> -
>> -  gdbpy_ref<thread_object> thread_obj;
>> -  struct threadlist_entry *next;
>> -};
>> +using thread_map_t = std::map<thread_info *, gdbpy_ref<thread_object>>;
> 
> You probably want to use unordered_map, which is preferable when we
> don't care about key order.

Will do in the V2!

Thanks,
Lancelot.

> 
> Every time someone introduces a use of a map, there's the topic of "but
> hashtab is faster than std::unordered_map" that comes but, and the fact
> that gcc has some C++ bindings for it, and that we should import and use
> it, but that it was never done because its "empty" method confusingly
> empties the map, rather than returning whether the map is empty.  But
> still, I think that std::unordered_map is preferable over std::map.
> 
> I haven't checked the rest of the patch, since Tom already has.
> 
> Simon