[
https://issues.apache.org/jira/browse/AVRO-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818481#comment-17818481
]
Avi Levin commented on AVRO-3831:
---------------------------------
I'm willing to take this one if/when there is an interested maintainer
available for questions and PR reviews
> Async support for C#
> ---------------------
>
> Key: AVRO-3831
> URL: https://issues.apache.org/jira/browse/AVRO-3831
> Project: Apache Avro
> Issue Type: Improvement
> Components: csharp
> Reporter: Avi Levin
> Priority: Minor
>
> De/serialization libraries in .NET are expected to support asynchrony for
> reasons well-described for example
> [here|https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices?view=aspnetcore-8.0#avoid-blocking-calls]:
> {quote}Asynchronous APIs allow a small pool of threads to handle thousands of
> concurrent requests by not waiting on blocking calls. Rather than waiting on
> a long-running synchronous task to complete, the thread can work on another
> request [...] Many synchronous blocking calls lead to Thread Pool starvation
> and degraded response times.
> {quote}
> The first step would be to add async equivalents to each method in the
> {{Encoder}} and {{Decoder}} implementations, using the async methods in
> {{Stream}} for its implementation. (There is a "[flag-argument
> hack|https://stackoverflow.com/a/54267939/1180926]" pattern used in many
> libraries, including the Azure SDK, to prevent code duplication between the
> sync and async copies of otherwise identical methods.)
> Upstream libraries like {{DataFileReader/DataFileWriter}} can be updated once
> the en/decoders have been.
> AVRO-2252 requested this, but as far as I can tell it never got backlogged in
> any of the issues mentioned there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)