Stephen Cleary

Sorry I missed this! The reasoning is summarized here: https://blog.stephencleary.com/2013/04/cancellationtoken-behavior-with-asyncex.html It is a way to do "try" behavior, for one meaning of "try"; the multiple meanings of "try" are why...

I'll consider it, but any changes like this need to be made across the whole library - i.e., we'd also need a named `AsyncSemaphore`, named `AsyncManualResetEvent`, etc.

See also https://github.com/StephenCleary/AsyncEx/pull/16 I'm wondering if it would be possible to create some kind of naming wrapper?

Another reference-counted approach: https://stackoverflow.com/a/31194647/263693

Yes, the `bool sync` technique is described here: https://msdn.microsoft.com/en-us/magazine/mt238404.aspx

I'll take a look. I'm generally against recursive locks for design reasons: https://blog.stephencleary.com/2013/04/recursive-re-entrant-locks.html But I understand their appeal. Until the latest version of AsyncEx, it shipped with example code that...

I'm closing this as expected behavior. An `async void` method surfaces its exceptions by throwing them directly on the `SynchronizationContext`, by design. In this sense, they are "top level" exceptions....

> ThreadPool is unavailable in UWP with target lower than Fall Creators Update Well, that's unfortunate. UWP *claims* to support `ThreadPool` even in the original `10.0`. Changing `WaitHandles` to `netstandard1.6`...

Note to self: it may be better to use UWP-specific versioned dependencies so that UWP pre-16267 will not attempt to pull in `WaitHandles` at all.

Good point. I don't remember why that method has `EditorBrowsableState`, but I believe you are correct: it shouldn't be that way. Using `ConfigureAwait(false)` is fine with `AsyncLazy`.