[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-dd-dev] Memory service questions
|
Ted Williams wrote:
Jesper Eskilson wrote:
Pawel Piech wrote:
No this is actually intentional. The cache in the memory block is
used to implement the manual update policy where the memory view is
updated only per request.
Yes, apparently, but *why*? I don't see the connection between update
policy and caching strategy.
Update policy determines when the view should read only from the cache
and when it should invalidate the cache and read from the target.
This sound weird to me. Normally, a cache's only task is to make reads
(and writes) faster, and should have *zero* effect on the view of the
system (think about how a normal (hardware) memory cache works).
Update-policies are (as I understand them) a way for the user to dictate
when to retrieve new values from the debugger. How and when the cache
kicks in is an implementation issue in the backend. If the user selected
"automatic", i.e. update the view each time the UI asks for it, it is
*still* up to the backend (DsfMemoryBlock or the memory service) to
determine if the cache is still valid. If the cache is still valid, the
is no reason to go and ask the debugger.
Anyway, this is not an important issue, since enabling cache for
automatic update policies doesn't solve the issue at hand, it just
pushes the problem to the DsfMemoryCache.
What is your host platform? Do you see similar results from clicking the
scrollbar arrows? This sounds like a rendering defect.
Linux/GTK2, but I think we're seeing the same behavior on Windows hosts.
When I click the scrollbar arrows I get between 5 and 20 identical requests.
This definitely sounds like a rendering defect.
--
/Jesper
