#ROBOMERGE-SOURCE: CL 14629445 via CL 14629451 via CL 14629453 via CL 14629688 via CL 14629956 via CL 14630024
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v753-14616146)
#ushell-cherrypick of 14632086 by graeme.thornton
[CL 14784442 by Matt Peters in ue5-main branch]
#rb rune.stubbe
#jira none
#rnx
#ROBOMERGE-SOURCE: CL 13007135 in //UE4/Release-4.25/... via CL 13007150 via CL 13007159
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v682-12900288)
[CL 13007166 by jeff newquist in Main branch]
Normal read requests have this behavior, but size requests were not respecting this, which caused problems when the constructor launches a callback on another thread and then immediately calls WaitCompletion, such as in the callback lambda inside FFileCacheHandle::FFileCacheHandle / PushCompletedRequest.
#rb rune.stubbe
#jira none
#rnx
#ROBOMERGE-SOURCE: CL 12974187 in //UE4/Release-4.25/... via CL 12974195 via CL 12974203
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v682-12900288)
[CL 12974208 by jeff newquist in Main branch]
[RN] Minor, PakFiles
#ROBOMERGE-SOURCE: CL 12502978 via CL 12502983 via CL 12502984
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v673-12478461)
[CL 12502987 by matt peters in Main branch]
#rb steve.robb
#ROBOMERGE-SOURCE: CL 12450992 via CL 12450999 via CL 12457993
#ROBOMERGE-BOT: (v672-12450963)
[CL 12458149 by johan torp in Release-Engine-Staging branch]
[FYI] johan.torp, steve.robb, eric.knapik
#rnx
#ROBOMERGE-SOURCE: CL 12434782 via CL 12434783 via CL 12437070
#ROBOMERGE-BOT: (v671-12333473)
[CL 12443982 by david hamm in Release-Engine-Staging branch]
#rb steve.robb, eric.knapik
#ROBOMERGE-SOURCE: CL 12371098 via CL 12372591 via CL 12388959
#ROBOMERGE-BOT: (v671-12333473)
[CL 12390565 by johan torp in Release-Engine-Staging branch]
Legacy pak file versions encode pak entries in FPakFile::LoadLegacyIndex. That function repeatedly serializes bytes from the pakfile on disk into a reused FPakEntry. Serialize expects the FPakEntry to be in an empty constructed state, and it was not empty due to serializing previous PakEntries into it.
Added a reset function and call it in this one place where FPakEntry is reused.
#rb Graeme.Thornton
#rnx
[CL 12000363 by Matt Peters in Main branch]
#rb none
#testing iOS Client
#ROBOMERGE-SOURCE: CL 11843182 via CL 11843195 via CL 11843203
#ROBOMERGE-BOT: (v656-11643781)
[CL 11879820 by thomas ross in Main branch]
This was originally fixed in CL 11458603 but it did not fix the issue entirely and in any case I was not happy with the manual reset event approach.
The problem with the manual reset event was that there is no actual safe point at which we can reset the event without risking some requesting thread missing it and waiting forever, it is just a lot rarer than the original thread lock.
- Each FChunkRequest now can be given an event that is triggered, so the correct thread is always woken up if waiting.
- Since the signals are 1-1 we no longer risk having threads never being woken.
- We only wake the thread that has a request to process so don't risk flooding the cpu.
- Removed FChunkCacheWorker::SetupDecryptionKey as it was not implemented/used.
- Removed FChunkCacheWorker::ChunkRequestAvailable and its associated methods ::WaitForNextChunk/::FlushRemainingChunkCompletionEvents.
In testing this version runs slightly faster on loading tests (0.2seconds on average), although just removing the events entirely and running a busy loop with a yield ran slightly faster on machines with less cores (4 cores with hyperthreading or less) albiet with a much higher variation and so potentially could end up a lot worse.
#rb Graeme.Thornton
#jira UE-89165
#ushell-cherrypick of 11724338 by paul.chipchase
#ROBOMERGE-SOURCE: CL 11724753 in //UE4/Release-4.25/... via CL 11724760
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v656-11643781)
[CL 11724764 by paul chipchase in Main branch]
