IAsyncEnumerable support

I have created a converter to add support for IAsyncEnumerable<T> to Newtonsoft.Json. I explored doing this directly in the Newtonsoft.Json codebase, but because it targets much older framework versions, I deemed this to be infeasible. Instead, I have created a separate library that contains a converter that can be registered to provide bidirectional conversion. As a separate library, it can target .NET Standard 2.0 and use C# 8 and not have to worry about the older framework versions that the main library supports (implementing IAsyncEnumerable is impossible in pretty much everything in the list other than netstandard2.0).

I think it would be good to publish this as an easily-discoverable NuGet package, e.g. with the name Newtonsoft.Json.AsyncEnumerable. Is there any chance that it might be accepted into the Newtonsoft.Json codebase in order that it be published in this way?

If not, what would the etiquette be around publishing a NuGet package with that ID under my own ownership? Making it perfectly clear of course in all descriptions & documentation that I was not affiliated with James Newton-King or the .NET Foundation.

[logiclrd]

I just Googled this, and found a site outlining the following scenario:

• The thread pool has a limited number of threads. On my system this limit is not tiny (4K for my memory/architecture) but it is nevertheless quite finite.
• With sync over async, the thread initiating the operation might itself be a thread pool thread. Each new operation that comes in pulls a thread from the pool.
• It invokes the async operation, which sets up an underlying I/O and then returns. When that I/O is completed, it queues up a thread pool action to process it.
• While the async operation is running, the sync part at the top has to wait for it, which means blocking that thread pool thread it is occupying.
• If you manage to get as many overlapping I/O operations as there are thread pool threads, then the entire thread pool will be occupied by those sync top ends blocking on the completion of the underlying I/O operations. When those I/O operations complete, their continuations won’t ever get scheduled because there are no free threads.

Thus, a deadlock arises.

So, my converter is only a band-aid – it works in constrained testing scenarios, but wouldn’t be a reliable scenario in a service scenario.

[logiclrd]

Then I fear ASP.NET Core will never properly support IAsyncEnumerable. 😦 I’ll have to think about whether there might be some architecture to make it discoverable whether a formatter properly supports IAsyncEnumerable.