Prepare RPCInverse ESProducers for concurrent IOVs #24511
Conversation
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-24511/6373 |
|
A new Pull Request was created by @wddgit (W. David Dagenhart) for master. It involves the following packages: CondTools/RPC @ggovi, @cmsbuild can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
+1 |
cmsbuild
added
db-approved
fully-signed
and removed
db-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
Currently the Framework only allows one EventSetup IOV (Interval of Validity) to be processed at a time, but we are preparing to change this in the future and allow multiple concurrent IOVs. This PR modifies the ESProducers related to RPCs in preparation for this change.
Prior to this, the ESProducer held a pointer to a single produced object. After this PR it will use the ReusableObjectHolder class to manage multiple objects, one for each concurrent IOV. The objects needs to hold different content for different IOVs and the ESProducer needs to modify them during its produce call in a thread safe manner.
The dependsOn feature of the EventSetup has difficulty communicating with these different objects in the callbacks and produce function calls. The usage of the dependsOn feature is replaced by usage of the new ESProductHost class. It has a similar purpose, but works better when there are multiple IOVs because its interface allows direct communication via arguments between the produce methods and the lambda function that gets called when the dependent record changes.
Note, I could not find anything in CMSSW that actually uses these modules. (It is possible they are not needed at all.) The standard tests I tried do not run them, so to test I manually created a test configuration that runs them and stepped through in the debugger to see they were performing as I expected.