<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 3, 2014, at 9:12 PM, Kuba Brecka <<a href="mailto:kuba.brecka@gmail.com" class="">kuba.brecka@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="im" style="font-family:arial,sans-serif;font-size:13px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">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.</div>
</blockquote><div class=""><br class=""></div></div><div style="font-family:arial,sans-serif;font-size:13px" class="">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px" class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>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</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div style="font-family:arial,sans-serif;font-size:13px" class="">Btw. does SBValue do any caching? </div></div></div></div></blockquote><div><br class=""></div><div>Not SBValue directly; ValueObjects do.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div style="font-family:arial,sans-serif;font-size:13px" class="">Does it get invalidated when the program is allowed to run?</div></div></div></div></blockquote><div><br class=""></div><div>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</div><div><br class=""></div><div>int foo() {</div><div> int x;</div><div><b class=""> someCode();</b></div><div> someMoreCode();</div><div> return 0;</div><div>}</div><div><br class=""></div><div>You’re stopped on the someCode() call. and you fetch a ValueObject for “x”; that’s all fine and dandy right.</div><div>Now you step over, and you’re stopped on someMoreCode()</div><div>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</div><div><br class=""></div><div>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</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">
<div class="im" style="font-family:arial,sans-serif;font-size:13px"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">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.</div></blockquote>
<div class=""><br class=""></div></div><div style="font-family:arial,sans-serif;font-size:13px" class="">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</div></div></div></div></blockquote><div><br class=""></div><div>I see this comment in ThreadList.h:</div><div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0);" class="">// FIXME: Currently this is a thread list with lots of functionality for use only by</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0);" class="">// the process for which this is the thread list. If we ever want a container class</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0);" class="">// to hand out that is just a random subset of threads, with iterator functionality,</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0);" class="">// then we should make that part a base class, and make a ProcessThreadList for the</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0);" class="">// process.</div><div class=""><br class=""></div><div class="">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-<i class="">y</i> smarts</div><div class="">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</div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">
<div style="font-family:arial,sans-serif;font-size:13px" class=""><br class=""></div><div style="font-family:arial,sans-serif;font-size:13px" class=""> SBThreadList SBProcess::GetMemoryHistoryThreadsForAddress(addr_t addr);</div><div style="font-family:arial,sans-serif;font-size:13px" class="">
<br class=""></div><div style="font-family:arial,sans-serif;font-size:13px" class="">which might make more sense than from SBValue. Would you prefer that?</div></div></div></div></blockquote><div><br class=""></div><div>To me, that is a very very sound base API</div><div>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!</div><div><br class=""></div><div>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</div><div>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!</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div style="font-family:arial,sans-serif;font-size:13px" class=""><br class=""></div><div style="font-family:arial,sans-serif;font-size:13px" class="">
Kuba</div><div style="font-family:arial,sans-serif;font-size:13px" class=""><br class=""></div></div></div>
</div></blockquote></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thanks,</div><div class=""><i class="">- Enrico</i><br class="">📩 egranata@<font color="#ff2600" class=""></font>.com ☎️ 27683</div><div class=""><br class=""></div></div></div></div></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>