[ 
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)

Reply via email to