MultiThread: Fix initial period prediction in multithread mode #1628
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While checking why some tests on #1627 didn't pass I realized that this was due to an actual real performance issue in multithread mode in rare scenarios.
Basically, the
WorkerMain
module - whose role is to setup everything worker-side in multithreaded mode - gives a hint of what could be expected to be the first Period to load in the content.However, it always gave the first Period - I guess we put a placeholder when first writing the code and forgot to replace it until now.
As this is only a hint, this doesn't really led to any important issue, the only visible problem - and why some integration tests failed sometimes - were that the actual module relying on that information took some time (the next playback observation so from 0 to 1 second) before correcting the value.
In very specific scenarios, this could mean loading 1 second later than usual (this wasn't really visible on initial load here but it happened in tests for RELOADING cases).