Community
Participate
Working Groups
Created attachment 113929 [details] Patch with the proposed DataCache object. This bugs comes from investigation of TCF's TCFDataCache and TCFChildren classes. These object solve a common asynchronous programming pattern where multiple clients request the same piece of data. Currently in DSF, there is a CommandCache object. However, the CommandCache is specific to using the ICommand interface and it is also dependent on data model contexts. In contrast, the proposed data and elements cache objects would be very simple cache utilities which could in turn be used as building blocks for a more complex caching strategy such as the CommandCache.
Created attachment 114209 [details] Initial DataCache unit test.
I tried using it. It’s almost what I was looking for. The only surprise I had was - I was expecting retrieve to be called only once. Once the cache is in a pending state I didn’t expect retrieve to be called again.
(In reply to comment #2) > I tried using it. It’s almost what I was looking for. > > The only surprise I had was - I was expecting retrieve to be called only once. > Once the cache is in a pending state I didn’t expect retrieve to be called > again. > That's why it's only a proposal :-) Seriously though, that's a bug in the proposed implementation, i.e. retrieve is supposed to be called only once. If you end up fixing and using this object, please post the fixed version. I think we'll need a use case somewhere in open source before we can commit this object as an API, but with your help we'll get there sooner.
> If you end up fixing and using this object, please post the fixed version. I will. I want to test the faling path before I prepare the patch. Also, does it make sense the cache to have a reference to the data as well? > I think we'll need a use case somewhere in open source before we can commit this object as an API, but with your help we'll get there sooner. I don't understand. Can you epxlain a bit more?
(In reply to comment #4) > > If you end up fixing and using this object, please post the fixed version. > > I will. I want to test the faling path before I prepare the patch. > Also, does it make sense the cache to have a reference to the data as well? > Great :-) The cached DataRequestMonitor already has a reference to the data and/or the status. You could add a reference to it in the DataCache class, but it would be redundant. > > I think we'll need a use case somewhere in open source before we can commit this object as an API, but with your help we'll get there sooner. > > I don't understand. Can you epxlain a bit more? > I don't know how CDT has treated this requirement historically. However, in general when we add a new API (whether an interface, a utility class, etc.) we also like to see a use case for that API in open source. This gives us some way of testing this API and it allows others who are looking at the API to see an example of how its used. For example, when we developed the whole DSF framework we decided that we needed DSF-GDB to be written along with it even though Wind River didn't really need it. There are some features in the DSF API which are not used by the DSF-GDB implementation, so for testing and demonstration purposes I added an implementation of these APIs in the PDA debugger example. The reason I didn't check in DataCache in the first place, besides the fact that I didn't test it very well, is that I didn't have any object using it in CDT. As I mentioned in previous comment, I was thinking of refactoring CommandCache to use it, but I never had enough time to look at that. If you would like to implement and contribute a use case for this class in DSF, DSF-GDB, or DSF-PDA, then I think we could commit this class right away. Otherwise, I think we should leave this enhancement open and you can just copy DataCache into your commercial code (provided you will still honor EPL license requirements and make your improvements to this code freely available to the community :-)).
Since this class is not in CVS I'm not sure how to apply a patch on top of a patch. Do I just create a patch with the new version? I looked briefly at CommandCache. I don't feel confident yet to refactor it. For now I'll just copy the class locally. I believe as I get more familiar with DSF I will find a good use for the class. I think Marc from Ericsson mentioned using this pattern in MIVariableManager.
Created attachment 142574 [details] minor fixes
Comment on attachment 142574 [details] minor fixes Thank you Dobrin
