================
@@ -47,6 +46,9 @@ class SaveCoreOptions {
void AddMemoryRegionToSave(const lldb_private::MemoryRegionInfo ®ion);
+ std::optional<lldb::ThreadSP> GetThreadAtIndex(uint32_t idx) const;
----------------
Jlalond wrote:
We can, I'm personally willing to trade the complexity for the performance
wins. I think we have some minor complexity gain, primarily in the RemoveThread
option, but the insertion case is quite simple. I rationally understand we may
only today have a small number of threads, but I could imagine a world where we
want to save a huge amount of threads, Potentially even GPU threads!
I agree the added complexity is ugly and only to maintain the insertion order.
I think alternatively it would be nice if we could give out something akin to
an SBIterator. As we only need to maintain the order today due to the caller
only having access via index. Every usecase I can forsee will enumerate all
threads, individual indexing isn't necessarily valuable.
https://github.com/llvm/llvm-project/pull/122541
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
