> On Sep 3, 2014, at 9:12 PM, Kuba Brecka <[email protected]> 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
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
