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

[Enrico Granata]

> On Sep 3, 2014, at 9:12 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote:
> 
> 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.
> 

Then what you probably want is to cache the list in the plugin and gate the validity of the cache on the StopID; if you know your cached list was fetched at stopid==3, you can keep serving it as long as stopid==3; as soon as that changes, then - wipe the cache, and refetch

> Btw. does SBValue do any caching?

Not SBValue directly; ValueObjects do.

> Does it get invalidated when the program is allowed to run?

The way it works is that the ValueObjects are supposed to be able to “refresh” themselves, as long as their “context” is alive. Imagine the following

int foo() {
 int x;
 someCode();
 someMoreCode();
 return 0;
}

You’re stopped on the someCode() call. and you fetch a ValueObject for “x”; that’s all fine and dandy right.
Now you step over, and you’re stopped on someMoreCode()
The same “x” is still alive and in scope, so the goal is for the same ValueObject to be able to “refresh” itself - fetch a new value, a new summary, new children, … all without needing to discard the existing object and grab a new one

Now you step out of “foo()” entirely; “x” is now gone. At this point, the ValueObject is setup to understand the underlying value it represents has gone away - it should “freeze dry” itself, i.e. it will refuse to refresh itself, and keep providing the old answers to any questions it answered while alive, and refuse to provide answers to any new questions

>  
> 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

I see this comment in ThreadList.h:
// FIXME: Currently this is a thread list with lots of functionality for use only by
// the process for which this is the thread list.  If we ever want a container class
// to hand out that is just a random subset of threads, with iterator functionality,
// then we should make that part a base class, and make a ProcessThreadList for the
// process.

It seems like this was already thought of.. so, yes, by taking on some additional work you could certainly make a ThreadList be just that-  a list of threads - and have a ProcessThreadList be the subclass that handles all the process-y smarts
Then, your SBThreadList would wrap a ThreadListSP - and all would be merry - you could cache in the plugin per stop-id as an optimization, or you could entirely not do that, and just return a new list whenever you’re asked

> 
>   SBThreadList SBProcess::GetMemoryHistoryThreadsForAddress(addr_t addr);
> 
> which might make more sense than from SBValue. Would you prefer that?

To me, that is a very very sound base API
SBValue::GetHistoryThreads() makes sense as an helper - as in, Xcode would probably prefer to just use that, but all it would do is value->GetProcess()->GetHistoryThreads(value->GetPointerValue()) // pseudo-code!

Oh, one more little thing - when you do provide these APIs, unless they truly only make sense at the SB layer, it would be best to provide them on the internal objects (e.g. ValueObject::GetHistoryThreads(), Process::GetHistoryThreads(), …) and then have the SB objects just call into their internal counterparts
That way, we have one true implementation that we can use internally, as well as exposed to external users with very low risk of additional bugs/code duplication!

> 
> Kuba
> 

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683




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