Improve submitter client ext #39
Conversation
Api/csharp/ArmoniK.Api.Client/Submitter/ReadOnlyByteArrayPayload.cs
Outdated
Show resolved
Hide resolved
Api/csharp/ArmoniK.Api.Client/Submitter/ReadOnlyByteMemoryPayload.cs
Outdated
Show resolved
Hide resolved
| /// <exception cref="Exception">a result reply chunk is not data, rending it impossible to reconstitute the data</exception> | ||
| /// <exception cref="ArgumentOutOfRangeException">result reply type is unknown</exception> | ||
| [PublicAPI] | ||
| public static Task<Stream> GetResultAsStreamAsync(this gRPC.V1.Submitter.Submitter.SubmitterClient client, |
There was a problem hiding this comment.
@aneojgurhem With the stream correctly implemented, it is not necessary for this function to be async. Do we remove the async?
There was a problem hiding this comment.
We can keep it for now
| { | ||
| internal class ReadOnlyByteArrayPayload : ReadOnlyByteMemoryPayload | ||
| { | ||
| public ReadOnlyByteArrayPayload(byte[] bytes) |
There was a problem hiding this comment.
Why not just add a second constructor to the parent class?
| /// <summary> | ||
| /// IO.Stream that is read from an IAsyncEnumerable | ||
| /// </summary> | ||
| public class AsyncEnumerableStream : Stream, IAsyncDisposable |
There was a problem hiding this comment.
Lots of hypothesis on how it will be consumed.
Many of them will likely appear to be wrong.
This should be in another PR with lots of test and with microbenchmarks corresponding to different consumption use cases. These benchmarks should include both asynchronous and synchronous scenarios. In real application, the later are more likely as legacy deserializers are synchronous. None of the existing libs are using Memory or Span to get the data from the Stream.
|
|
fix aneoconsulting/ArmoniK#512