Feature Description: Better Dependent Analyses support
Hello,
While developing custom analyses, I found the need to make them dependent on each other. Looking online and in the linux kernel cpu analysis provided by this project, I've seen usage of the form
TmfTraceUtils.getAnalysisModuleOfClass( getTrace(), MyDependency.class, MyDependency.ID); inside an overriden getDependentAnalyses(). Example here
However, looking into the source code, this strategy is not useful at all for initial load of a trace with automatic analyses that have dependencies. This call leads to a chain of methods culminating in accessing a map in this file through the following getter: at line 337.
Looking at the order the analyses are run, we can see that the variable the getter accesses is not filled until after all automatic analyses are ran. at line 878. In that way, the getter is only useful after all the analyses are made, which defeats the purpose of using it to look for dependent analyses when opening a trace for the first time.
I would like to know whether I am managing these dependent analyses in a improper manner or if there is a better way to deal with them. For now, I've instead relied on ordering my plugin.xml to start the analyses in a specified order that satisfies the dependencies but that does not seem robust.
I've also linked a Pull Request which adds a minimal change to the TmfTrace class in org.eclipse.tracecompass.tmf.core.trace.TmfTrace . In it, simply loop over all discovered available analyses from the source files and add each of them to the Map that is ultimately used when calling
TmfTraceUtils.getAnalysisModuleOfClass( getTrace(), MyDependency.class, MyDependency.ID);
. As such, an automatic scheduled module analysis gets to acquire its dependent analyses from the getAnalysisModuleOfClass function.
The rationale behind this goes as follows:
-
The fAnalysisModules map is updated at the end of the function after all automatic modules, from the list of all discovered module analyses, have been scheduled. The only possible issue I could foresee is another class accessing the automatic modules assuming it is already completed when it was just added to the map for dependent builds discovery. However, this raises questions about the use of fAnalysisModules and what it represents. I simply thought of it as a list of non-null analysis modules and so I thought my change did not violate any basis of the use of that Map. If I am wrong, please correct me!
-
I thought of adding a new map with new helper functions but I thought that way would be too convoluted, and some people may have already been using the syntax TmfTraceUtils.getAnalysisModuleOfClass( getTrace(), MyDependency.class, MyDependency.ID); for their dependent builds.
Feature Description: Better Dependent Analyses support
Hello,
While developing custom analyses, I found the need to make them dependent on each other. Looking online and in the linux kernel cpu analysis provided by this project, I've seen usage of the form
TmfTraceUtils.getAnalysisModuleOfClass( getTrace(), MyDependency.class, MyDependency.ID);inside an overridengetDependentAnalyses(). Example hereHowever, looking into the source code, this strategy is not useful at all for initial load of a trace with automatic analyses that have dependencies. This call leads to a chain of methods culminating in accessing a map in this file through the following getter: at line 337.
Looking at the order the analyses are run, we can see that the variable the getter accesses is not filled until after all automatic analyses are ran. at line 878. In that way, the getter is only useful after all the analyses are made, which defeats the purpose of using it to look for dependent analyses when opening a trace for the first time.
I would like to know whether I am managing these dependent analyses in a improper manner or if there is a better way to deal with them. For now, I've instead relied on ordering my plugin.xml to start the analyses in a specified order that satisfies the dependencies but that does not seem robust.
I've also linked a Pull Request which adds a minimal change to the
TmfTraceclass inorg.eclipse.tracecompass.tmf.core.trace.TmfTrace. In it, simply loop over all discovered available analyses from the source files and add each of them to the Map that is ultimately used when callingTmfTraceUtils.getAnalysisModuleOfClass( getTrace(), MyDependency.class, MyDependency.ID);. As such, an automatic scheduled module analysis gets to acquire its dependent analyses from the getAnalysisModuleOfClass function.
The rationale behind this goes as follows:
The
fAnalysisModulesmap is updated at the end of the function after all automatic modules, from the list of all discovered module analyses, have been scheduled. The only possible issue I could foresee is another class accessing the automatic modules assuming it is already completed when it was just added to the map for dependent builds discovery. However, this raises questions about the use of fAnalysisModules and what it represents. I simply thought of it as a list of non-null analysis modules and so I thought my change did not violate any basis of the use of that Map. If I am wrong, please correct me!I thought of adding a new map with new helper functions but I thought that way would be too convoluted, and some people may have already been using the syntax
TmfTraceUtils.getAnalysisModuleOfClass( getTrace(), MyDependency.class, MyDependency.ID);for their dependent builds.