[Lldb-commits] [PATCH] [lldb] ASan history threads SB API

[Kuba Brecka]

>
> When would the list be invalidated? If the list can turn wrong without
> anyone being made aware of it, and your only hope is to fetch the data
> again, or risk failure, then no level of caching makes sense.
>

My reason to add that "cache" was not really to cache the data, but to be
able to iterate through the list of threads without having a SBThreadList
object. We don't really have a way of knowing when the data changed, but
the don't change when the program is stopped and they can change everytime
the program is allowed to run.

Btw. does SBValue do any caching? Does it get invalidated when the program
is allowed to run?


> That's not a bad idea. Just like SBValue has a ValueImpl, SBThreadList
> would have an Impl object. The Impl would contain a set of
> ThreadSP/SBThread objects and return those when asked.
>

That sounds reasonable and would solve this, if we're fine with
SBThreadList not being the SB equivalent of ThreadList. I could then expose
the API from anywhere, let's say as

  SBThreadList SBProcess::GetMemoryHistoryThreadsForAddress(addr_t addr);

which might make more sense than from SBValue. Would you prefer that?

Kuba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140903/a45ed25e/attachment.html>