Skip to content

TProcessID: Resetting Object Count after each Event

Simon Spannagel requested to merge multithreading_tprocessid into multithreading

This should solve the remaining (mostly cosmetic) issue with the overflow of the TProcessID. The problem (descibed here) was that the TProcessID table was overflowing, spilling over into TExMap with many obhjects being processed. In a multithreaded environment there wasn't really a way to reset the count because some events were always on the fly.

Now with !338 (merged) in, we actually don't have any TRef instances during event processing, and the issue is much more localized to the function call of Object::petrifyHistory() in the ROOTObjectWriter where TRef objects are generated and therefore the TProcessID object count is incremented. Since this is in a BufferedModule instance and therefore is mutexed, we do know that we can safely read the current object count and reset it to that value after processing this single event (compare ROOT documentation).

Tadaa 🎉 solved.

Merge request reports