-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
refactor(Core/Misc): Use steady_timer instead of deadline_timer #20940
Conversation
@Kitzunu what test(s) need to be done in order to test this change? |
Nah it works with all boost. The timers touch
|
I think its working. Compile is fine. Timers in boss fights too. Realm holds up fine too. Metrics look good to me too. I wanted to check ban expiration by using As far as this PR is concered i tested it and couldnt observe a noticable difference. |
I will merge it tomorrow. I avoid doing new merge before the CC update. |
Please merge master for CI codecheck fix |
This will fix mac os ci too |
…er (azerothcore#20940)" This reverts commit 0bc7067.
…er (azerothcore#20940)" This reverts commit 0bc7067.
…line_timer (azerothcore#20940)"" This reverts commit 807d371.
…line_timer (azerothcore#20940)"" This reverts commit 807d371.
Changes Proposed:
This PR proposes changes to:
Swap deadline_timer to steady_timer as it started to deprecate in boost 1.7 and is completely deprecated in 1.78.
This allows AC to run on Boost 1.78, as well as earlier versions.
Tests Performed:
This PR has been:
I have started the worldserver.
No extensive tests have been done
How to Test the Changes:
Known Issues and TODO List:
How to Test AzerothCore PRs
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.