异步/等待并打开一个 FileStream? [英] async/await and opening a FileStream?

问题描述

在尝试确定我是否正确使用了 Stream 方法(例如 ReadAsync 和 CopyToAsync)时，我遇到了以下问题:C# 4.5 文件读取性能同步与异步

在这个问题中，我在接受的答案中阅读了以下内容:

<块引用>

最值得注意的是，您的异步"测试不使用异步 I/O；带文件流，你必须明确地以异步方式打开它们，否则您只是在后台线程上进行同步操作.

在他的异步 IO 代码中，他使用以下代码异步"打开 FileStream:

var file = new FileStream(filename, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, true)

所以我想知道您是否打算使用诸如 CopyToAsync 之类的方法，您是否应该像上面显示的那样打开底层 FileStream?以下:

File.Open(filename, FileMode.Open)

CopyToAsync 实际文档中的示例演示如何打开底层 FileStream:https://msdn.microsoft.com/en-us/library/hh159084(v=vs.110).aspx

如果底层FileStream的打开方式无关紧要，那么FileStream构造函数的useAsync参数是做什么的?>

解决方案

所以我想知道您是否打算使用诸如 CopyToAsync 之类的方法是否应该像上图那样打开底层的 FileStream?

是的.原因主要是历史原因.

首先，在 Windows 上，HANDLEs(包括文件句柄)必须使用异步标志显式打开/创建，如果你想对它们进行异步(OVERLAPPED)操作.>

但是，旧的 Windows 95/98/ME 系列仅支持串行异步操作端口和 IOCTL(设备驱动程序)句柄.该平台线不支持 磁盘文件 上的异步 I/O.而原来的.NET确实支持98/ME，所以原来的FileStream 只是使用了同步 I/O.我认为(但不是绝对肯定)APM 方法(如 FileStream.BeginRead)在 Win98/ME 上可能只是使用所谓的 "asynchronous delegates"(它只是执行一个同步方法，如 FileStream.Read 在线程池线程上).

所以，这就是文件流句柄在默认情况下不用异步标志打开的历史原因.

<块引用>

CopyToAsync 实际文档中的示例是如何演示的

不幸的是，很多 MSDN 示例的质量都很差.如果您从这是一个如何调用此特定方法的示例"的角度来处理它们，它们是可以的，但从这是一个使用此方法的生产质量代码示例"的角度来看，它们就不是很好了.

I came across the following question when trying to determine if I was using the Stream methods such as ReadAsync and CopyToAsync correctly: C# 4.5 file read performance sync vs async

In this question I read the following in the accepted answer:

Most notably, your "async" test does not use async I/O; with file streams, you have to explicitly open them as asynchronous or else you're just doing synchronous operations on a background thread.

In his asynchronous IO code he was using the following to open the FileStream 'asynchronously':

var file = new FileStream(filename, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, true)

So I was wondering if you intend to use methods such as CopyToAsync whether you should open the underlying FileStream as shown above?, as opposed to doing something simple like the following:

File.Open(filename, FileMode.Open)

Which is how the example in the actual documentation for CopyToAsync demonstrates opening the underlying FileStream: https://msdn.microsoft.com/en-us/library/hh159084(v=vs.110).aspx

If it does not matter which way the underlying FileStream is opened, what does the useAsync parameter of the FileStream constructor do?

解决方案

So I was wondering if you intend to use methods such as CopyToAsync whether you should open the underlying FileStream as shown above?

Yes. The reason is mostly historical.

First, on Windows, HANDLEs (including file handles) must be opened/created explicitly with an asynchronous flag if you want to do asynchronous (OVERLAPPED) operations on them.

However, the old Windows 95/98/ME line only supported asynchronous operations on serial port and IOCTL (device driver) handles. Asynchronous I/O on disk files wasn't supported on that platform line. And the original .NET did support 98/ME, so the original FileStream just used synchronous I/O. I think (but am not absolutely sure) that APM methods (like FileStream.BeginRead) on Win98/ME were probably just implemented using the so-called "asynchronous delegates" (which just execute a synchronous method like FileStream.Read on a thread pool thread).

So, that's the historical reason why file stream handles were not opened with the asynchronous flag by default.

Which is how the example in the actual documentation for CopyToAsync demonstrates

Unfortunately, a lot of the MSDN examples are rather poor quality. They're OK if you approach them from the perspective of "here's an example of how to call this specific method", but not so great from the perspective of "here's an example of production-quality code that uses this method".

这篇关于异步/等待并打开一个 FileStream?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！