ArchiSteamFarm/packages/Nito.AsyncEx.4.0.1/lib/Xamarin.iOS10/Nito.AsyncEx.Enlightenment.xml

<?xml version="1.0"?>
<doc>
    <assembly>
        <name>Nito.AsyncEx.Enlightenment</name>
    </assembly>
    <members>
        <member name="T:Nito.AsyncEx.EnlightenmentVerification">
            <summary>
            Verifies platform enlightenment.
            </summary>
        </member>
        <member name="M:Nito.AsyncEx.EnlightenmentVerification.EnsureLoaded">
            <summary>
            Returns a value indicating whether the correct platform enlightenment provider has been loaded.
            </summary>
        </member>
    </members>
</doc>
Fix async/await with ConcurrentHashSet 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 2017-02-07 20:14:51 +01:00			`<?xml version="1.0"?>`
			`<doc>`
			`<assembly>`
			`<name>Nito.AsyncEx.Enlightenment</name>`
			`</assembly>`
			`<members>`
			`<member name="T:Nito.AsyncEx.EnlightenmentVerification">`
			`<summary>`
			`Verifies platform enlightenment.`
			`</summary>`
			`</member>`
			`<member name="M:Nito.AsyncEx.EnlightenmentVerification.EnsureLoaded">`
			`<summary>`
			`Returns a value indicating whether the correct platform enlightenment provider has been loaded.`
			`</summary>`
			`</member>`
			`</members>`
			`</doc>`