Use System.Buffers in System.IO.FileSystem

[stephentoub]

• Change FileStream to use ArrayPool<byte>.Shared for its internal buffer
• Add to Common a helper implementation of CopyToAsync that uses ArrayPool<byte>.Shared until such type as the base Stream (in mscorlib) can use a pooled buffer
• Utilize that CopyToAsync helper in FileStream

Having added that:

• Utilize that CopyToAsync helper in DeflateStream/GZipStream, as System.IO.Compression already depends on System.Buffers.

cc: @ericstij, @ianhays, @sokket, @KrzysztofCwalina
https://github.com/dotnet/corefx/issues/5598

[benaadams]

Break read+write dependency? e.g.

    byte[] buffer0 = ArrayPool<byte>.Shared.Rent(bufferSize);
    byte[] buffer1 = ArrayPool<byte>.Shared.Rent(bufferSize);
    return ArrayPoolCopyToAsyncInternal(source, destination, buffer0, buffer1, cancellationToken);
}

private static async Task ArrayPoolCopyToAsyncInternal(Stream source, Stream destination, byte[] buffer0, byte[] buffer1, CancellationToken cancellationToken)
{
    try
    {
        int bytesRead;
        Task<int> lastReadTask = source.ReadAsync(buffer0, 0, buffer0.Length, cancellationToken);
        Task lastWriteTask = Task.CompletedTask;
        bool otherBuffer = true;

        while ((bytesRead = await lastReadTask.ConfigureAwait(false)) != 0)
        {
            lastReadTask = source.ReadAsync((otherBuffer ? buffer1 : buffer0), 0, (otherBuffer ? buffer1 : buffer0).Length, cancellationToken);
            await lastWriteTask.ConfigureAwait(false);
            lastWriteTask = destination.WriteAsync((otherBuffer ? buffer0 : buffer1), 0, bytesRead, cancellationToken);
            otherBuffer = !otherBuffer;
        }
        await lastWriteTask.ConfigureAwait(false);
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer0);
        ArrayPool<byte>.Shared.Return(buffer1);
    }
}

[stephentoub]

I considered that but decided against it for the same reasons we didn't do so in the original Stream.CopyToAsync implementation. It leads to interesting concurrency issues that we decided to avoid in these core methods. For example, if the two concurrent read and write operations throw, which exception should we propagate, and what does that mean if there were important information in the other? And if the operations would actually end up consuming a thread pool thread to do a synchronous operation, do we really want to potentially be blocking two thread pool threads rather than one? Etc. If someone determines that they would really benefit from such overlapping, they can make that decision at the app level (where they have the ability to measure impact at the app-level) and write the few lines like you have themselves. Thanks, though.

[benaadams]

Makes sense

[ericstj]

LGTM

[justinvp]

Should this be NotSupported_UnwritableStream?

[stephentoub]

Yes, it should. Will fix.

[jonmill]

LGTM!