Make history registry non-singleton and also fix read calls to not use p... #681
Conversation
|
A new Pull Request was created by @wmtan for CMSSW_7_0_X. Make history registry non-singleton and also fix read calls to not use p... It involves the following packages: DataFormats/Provenance @vciulli, @Dr15Jones, @emeschi, @rovere, @deguio, @mommsen, @ktf can you please review it and eventually sign? Thanks. |
|
+1 I need this change merged into CMSSW_7_0_X before I can make a pull request for additional framework changes (given that we touch the same lines of code). All these changes are purely technical so I suggest bypassing signatures from the other L2s as long as a build test and the regular tests pass. I'm building the changes now, but given the large number of packages to be compiled it would probably be better to have this done centrally. |
|
I successfully built this and ran all the unit tests. The relvals are currently running, and all have passed so far. |
|
I have also successfullly built this. If Bill reports that the RelVal's all succeed, then please go ahead and bypass the signatures and merge into CMSSW_7_0_X. |
|
I ran the full relval matrix in CMSSW_7_0_X_2013-08-30-1400 with my changes. All tests except 143.0 passed, Even the two tests that are highlighted in red on the IB page passed for me. |
|
I reran test 143.0 and it failed in the cmsDriver step. I then reran 143.0 on the unchanged IB and got the same error. |
|
I then approve having this merged into 7_0_X |
|
@davidlt @nclopezo @smuzaffar @ktf To whom ever is handling CMSSW_7_0_X while Giulio's away, at your earliest convenience please bypass the rest of the signatures for this change (since it is purely technical) and merge it into the release. |
|
Just for future. If two features are not entangled together, they should be in two separate branches. Trusting @Dr15Jones and after testing bypassing it. If there are any issues in IBs, please report to this ticket. |
…reading Make history registry non-singleton and also fix read calls to not use p...
Thanks David. With the time difference it can some times be hard to figure out which IB is next. I assume this is in the 0200 build for Monday? |
|
@Dr15Jones correct, it's 0200 Monday IB. |
…ltipleStreamsInEventProcessor Resolved minor overlapping change in EventProcessor.cc and SubProcess.cc. In both cases the resolution was to use the change already in this branch.
Two different changes to the framework to support multithreading are being submitted together because they touch some of the same lines of code:
Change 1:
Functions that read a run, lumi, or an event principal fill in the principal that is passed in by reference. These functions no longer create the principal. Therefore, there is no need for them to return a pointer to the principal.
With this pull request, these functions now return void or bool, as appropriate. Furthermore, the functions that read a run or lumi principal were passed a shared pointer for filling. As this is no longer needed, we now pass references instead. Also, the functions readAndCacheRun and readAndCacheLumi were modified to fill in the principal rather than creating it, and were renamed readRun and readLuminosityBlock respectively, because the caching of the principal has been moved outside these functions.
Change 2:
The process history registry is redone so that it is no longer a singleton instance of the ThreadSafeRegistry template. It is now a separate class, and the primary input source, each secondary input sources, and each ROOT/EDM output module now each has its own instance of this registry.
This pull request contains and supersedes #641, which is being closed.