-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve MessageLogger context handling #34557
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-34557/24088
|
A new Pull Request was created by @wddgit (W. David Dagenhart) for master. It involves the following packages:
@makortel, @smuzaffar, @cmsbuild, @Dr15Jones can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-ff2bc4/16993/summary.html Comparison Summary@slava77 comparisons for the following workflows were not done due to missing matrix map:
Summary:
|
Hmh, workflow 1325.81 shows small differences in reco comparisons, |
@cmsbuild, please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-ff2bc4/17038/summary.html Comparison SummarySummary:
|
+1 |
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. @silviodonato, @dpiparo, @qliphy, @perrotta (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
Remove assertions recently added in pull request #34506 that caused problems documented in issue #34520. Even if the asserts uncovered a real problem, using the MessageLogger context system to test for this is probably not the best design. It was not my original intent. I thought it was just paranoid protection against something that couldn't happen.
Instead of asserting, the MessageLogger context will go into an "unknown state". The context line will print "unknown context" in the spot where the context normally goes.
This only affects the context printed in a MessageLogger message. It only affects it in the unusual case where one module ends, there was a previous module running/waiting when it started, the context for the previous module is not in one of the normally expected states.
This is a limited fix intended to address only the recent assert failure referenced above. Practically speaking, this is probably good enough, but as I implemented this I noticed there are issues in this part of the code which I did not try to fix. We might want to follow this up with more improvements.
MessageLogger is using thread locals and the ActivityRegistry to keep track of which module is currently running. Concurrent tasks and waits inside of module level transition functions could be problematic for this design. It worked perfectly before concurrency. We've discussed similar issues before. I think Chris has brought this up more than once.
We do not and have not ever set the context for the module transitions writeLumi, writeRun, and writeProcessBlock. I have not added support for that here. The specific case where the assert failed was related to writeLumi. This is something we could fix in the future although I've never noticed MessageLogger messages being printed in those contexts...
The other two possible GlobalContext states that might have caused those asserts to fail are kBeginJob and kEndJob. Those are handled in a different way which also could be problematic if those methods ever have sub transition function concurrency/waits in the future.
PR validation:
Relies on existing unit tests. This change only affects the response to behavior that should really not be happening.