|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
Back to the top