FChunkCacheWorker::ChunkRequestAvailable could have many threads waiting on it and would only wake up a single thread each time a FChunkBuffer is processed. There would be no guarantee that the correct thread would be woken up or that each thread would be woken a single time, meaning that sooner or later we would end up with the FChunkCacheWorker having no more work to process but a number of threads still idle, waiting on the event to wake them, which would never happen.
Switching to a manually reset event will cause all waiting threads to be woken each time the event is triggered and will make sure that we don't deadlock.
This issue showed up now due to changes else where in the code which resulted in more threads waiting on FChunkCacheWorker than we previously had.
#jira UE-88734
#rb graeme.thornton
[CL 11458603 by paul chipchase in 4.25 branch]
#rb steve.robb
#ROBOMERGE-SOURCE: CL 11303014 via CL 11303031 via CL 11303037 via CL 11303042
#ROBOMERGE-BOT: (v0-11244347)
[CL 11303201 by graeme thornton in Main branch]
Name the number in pakchunk file pakchunk index and the number of a platform chunk chunk id to avoid confusion. Also keep this naming convention consistent across all platform code.
#ROBOMERGE-SOURCE: CL 11131543 via CL 11132441 via CL 11132504
#ROBOMERGE-BOT: (v640-11091645)
[CL 11132564 by hongyi yu in Main branch]
Partially back out changelist 11106714, only keeping intended merged code
[FYI] Dan.Phillips
#ROBOMERGE-SOURCE: CL 11107908 via CL 11107911
#ROBOMERGE-BOT: (v640-11091645)
[CL 11107914 by bob tellez in Main branch]
Allow a read request to tell the pak cache not to keep the memory after the request is completed.
Make virtual textures give up their pak cache memory immediately after loading.
[REVIEW] ben.woodhouse, steve.robb, david.harvey
#ROBOMERGE-OWNER: dan.phillips
#ROBOMERGE-AUTHOR: dan.phillips
#ROBOMERGE-SOURCE: CL 11106543 via CL 11106714 via CL 11106736 via CL 11106740
#ROBOMERGE-BOT: (v640-11091645)
[CL 11106744 by dan phillips in Main branch]
#rb Justin.Marcus
#ROBOMERGE-SOURCE: CL 11064634 via CL 11064641 via CL 11064653
#ROBOMERGE-BOT: (v637-11041722)
[CL 11064661 by hongyi yu in Main branch]
Add some more stats for detecting bad seeks between pak files and contiguous reads
[FYI] ben.woodhouse
#ROBOMERGE-SOURCE: CL 10981267 via CL 10981268 via CL 10981271
#ROBOMERGE-BOT: (v632-10940481)
[CL 10981277 by dan phillips in Main branch]
#jira UE-86394
#rnx
#ROBOMERGE-SOURCE: CL 10925126 via CL 10925127 via CL 10925128
#ROBOMERGE-BOT: (v626-10872990)
[CL 10925130 by graeme thornton in Main branch]
[FYI] bob.tellez
#ROBOMERGE-SOURCE: CL 10903752 via CL 10903753 via CL 10903755
#ROBOMERGE-BOT: (v626-10872990)
[CL 10903757 by graeme thornton in Main branch]
#rnx
#rb none
#ROBOMERGE-OWNER: ryan.durand
#ROBOMERGE-AUTHOR: ryan.durand
#ROBOMERGE-SOURCE: CL 10869210 via CL 10869511 via CL 10869900
#ROBOMERGE-BOT: (v613-10869866)
[CL 10870549 by ryan durand in Main branch]
#jira
#rb Graeme.Thornton
#ROBOMERGE-SOURCE: CL 10791547 via CL 10791568 via CL 10791573 via CL 10791579 via CL 10791601
#ROBOMERGE-BOT: (v610-10636431)
[CL 10791615 by jamie dale in Main branch]
- Always look for pak files in the standard locations to determine whether we should create the platform layer
- When looking up a decryption key, check the registered list for all guids, even empty ones. We want to support pak mounting in non-monolithic builds where we don't have an embedded key.
- Remove the initialization-time check that the decryption key exists for pak files with an encrypted index. The condition to test is more complex when considering editor pak mounting, and we will get a meaningful error almost immediately afterwards anyway.
#ROBOMERGE-SOURCE: CL 10482630 via CL 10482631
#ROBOMERGE-BOT: (v606-10482310)
[CL 10482632 by graeme thornton in Main branch]
Fix up nearby cases where ESearchCase::CaseSensitive should have been used
#jira
#rnx
#rb
#ROBOMERGE-OWNER: marc.audy
#ROBOMERGE-AUTHOR: marc.audy
#ROBOMERGE-SOURCE: CL 10309793 via CL 10309818
#ROBOMERGE-BOT: (v593-10286020)
[CL 10309932 by marc audy in Main branch]
Replicated from CL# 7924370.
#rb none
#ROBOMERGE-OWNER: steve.robb
#ROBOMERGE-AUTHOR: steve.robb
#ROBOMERGE-SOURCE: CL 9279060 via CL 9279063
#ROBOMERGE-BOT: (v443-9013191)
[CL 9279836 by steve robb in Main branch]
#rb mickael.gilabert
#ROBOMERGE-SOURCE: CL 9167378 via CL 9167405 via CL 9167407
#ROBOMERGE-BOT: (v443-9013191)
[CL 9167408 by joe barnes in Main branch]
