Within the DQMStore, we have the functionality to write the classic TDirectory based output file. This needs to be preserved, since many (if not most) DQM-based tools consume DQM data in this format. Currently, we write this format at the end of production HARVESTING jobs, and in many less-mainstream workflows.
The existing code uses gDirectory and all the usual ROOT things in the classic ways [1], which as I understand is not threadsafe (or maybe it is, setting the correct options in ROOT?).
Now I wonder if the new saving code can reuse the old logic, or if we should use the occasion to do this in some more modern way [2]. Actually, I am not sure if there even is a better way. Any advice?
The old save API (where any module can call save on the DQMStore at any time to write a ROOT file) probably needs to be preserved (a number of niche workflows depend on that), but the main use case in HARVESTING might be possible to turn into a proper output module.
Dear framework experts,
Within the
DQMStore
, we have the functionality to write the classicTDirectory
based output file. This needs to be preserved, since many (if not most) DQM-based tools consume DQM data in this format. Currently, we write this format at the end of production HARVESTING jobs, and in many less-mainstream workflows.The existing code uses
gDirectory
and all the usual ROOT things in the classic ways [1], which as I understand is not threadsafe (or maybe it is, setting the correct options in ROOT?).Now I wonder if the new saving code can reuse the old logic, or if we should use the occasion to do this in some more modern way [2]. Actually, I am not sure if there even is a better way. Any advice?
The old
save
API (where any module can callsave
on theDQMStore
at any time to write a ROOT file) probably needs to be preserved (a number of niche workflows depend on that), but the main use case in HARVESTING might be possible to turn into a proper output module.[1] https://github.com/cms-sw/cmssw/blob/master/DQMServices/Core/src/DQMStore.cc#L2633-L2668 [2] I do plan to gt rid of the
lat::
dependencies, at least...