Until now it was 1:1 copy of en-US for silencing warning fixed in previous commit, remove it until we have a reason to add it back (with actually different translations from en-US)
Now this is a nice bug that was found accidentally by ArchiBoT...
ReaderWriterLockSlim() is very decent solution, but it's thread-based, and we're using our ConcurrentHashSet in mixed async/sync context. This means that if we use something like:
foreach (var item in concHashSet) {
await AnythingAsync().ConfigureAwait(false);
}
It's totally possible that we'll request read lock as thread 1, and release the read lock as thread 2, which will lead to RWLock exception => System.Threading.SynchronizationLockException: The read lock is being released without being held.
Fortunately it looks like we didn't have any scenario like this in ASF, as this was possible only when we async/await while enumerating over ConcurrentHashSet, so that specific bug didn't affect ASF codebase (yet). Still, I must fix this as current implementation is not thread-safe, so our HashSet is in fact not concurrent in the first place.
I analyzed possible solutions and there are basically 3: either using ConcurrentDictionary and wrapping around it, replacing lock with SemaphoreSlim, or using third-party AsyncReaderWriterLock from StephenCleary. SemaphoreSlim entirely kills the concept of multiple readers one writer, and could affect performance negatively, moreover - it doesn't support upgreadable lock scenario we have with ReplaceIfNeededWith(). Concurrent dictionary would be nice if I didn't have that awful memory hit from storing mandatory pointless value, plus I don't really like concept of wrapping around conc dictionary if I can simply use it right away and drop my conc hashset entirely. AsyncReaderWriterLock seem to be really well written, and works on Mono + should be compatible with .NET core in the future, so we should go for it as it's the best bet both performance-wise and memory-wise.
This brings another package dependency and changes a bit backend of ConcurrentHashSet
We should finally start using latest SK2 enhancements, some of which I added myself to official SK2 repo.
I hope this solves various network quirks that suddenly arrived either with Steam network, or ASF code changes regarding HeartBeats.
The .dll bin is self-compiled from latest SK2 repo, I hope I can drop it when SK2 arrives on nuget, but when it happens - not sure, while I want to test if this fixes particular issues that are happening lately.
ASF is AnyCPU binary which means it'll run fine on both 32-bit as well as 64-bit OSes.
Up to today 32-bit runtime was preferred for ASF, as it uses less memory and can be faster than 64-bit equivalent.
However, in very busy environments it's easily possible for ASF to require even more than 2 GB of memory, and in addition to that extending our userspace to 64-bit can bring benefits on more modern setups.
Therefore, keep being compatible on both 32-bit and 64-bit OSes, but on 64-bit ones use actual 64-bit runtime instead of preferred 32-bit one.
In addition to that, optimize some unused references and other things while we're at it.
