> > 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
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
