c# - Stream.ReadAsync 和 Stream.WriteAsync 是否应该在返回之前或操作完成之后同步更改光标位置？

Question

我一直在尝试实现一个支持 ReadAsync 和 WriteAsync 的 Stream，并考虑到 documentation 的冗余性，我正在努力了解如何正确执行此操作。具体来说，关于流的光标位置。问了一个类似的问题here和 here关于旧的 BeginRead 函数。该函数的文档似乎表明，在任何挂起的异步操作完成之前，不应再次调用 BeginRead。

鉴于 BeginRead 现在已弃用 no longer recommended for new development并且 Stream 可能已被显着改变以实现新的 Async 功能，事情再次不清楚。 (编辑:通常这种警告意味着新函数被直接实现，旧函数调用新函数并且仍然存在只是为了向后兼容，但这里似乎并非如此。

ReadAsync 和 WriteAsync 函数被定义为它们不会将所需的读/写流位置作为它们的 Win32。 counterparts做(我认为这是一个非常糟糕的设计选择)，而是依赖于流实现所持有的当前位置。如果满足以下两个条件之一，则这种情况很好:

1. ReadAsync 和 WriteAsync 必须获取当前光标位置供操作使用，并在返回前更新它，就好像操作已完成(或根本不更新) 任务，或者
2. 在所有先前的异步调用完成之前，不能调用 ReadAsync 或 WriteAsync。

在这两个条件之外，调用者永远无法确定读取或写入将发生的位置，因为挂起的异步操作可能会改变任何 Seek 和调用之间的流位置ReadAsync 或 WriteAsync。这些条件都没有记录为要求，所以我想知道它应该如何运作。

我的白盒测试似乎表明至少对于 Stream 的 FileStream 版本，流位置更新是异步的，这似乎表明第二个条件(仅允许一个挂起的操作)仍然是必需的，但这似乎是一个严重的限制(它肯定排除了任何类型的内部分散 - 聚集实现)。

谁能提供任何权威信息来说明旧的 BeginRead 限制是否仍然适用于 ReadAsync？

Answer 1

Can anyone provide any kind of authoritative information as to whether the old BeginRead limitation still applies to ReadAsync or not?

同样的限制适用于 BeginRead和 ReadAsync .

旧的 APM 方法尚未弃用。它们仍然得到完全支持，使用它们没有任何问题。然而，async方法相当容易使用，因此文档建议改用它们。

所有这些 async这些旧类的“重载”通常仍然包括调用 BeginXXX和 EndXXX或者最多两个选项都调用共享方法(例如 FileStream.BeginReadAsync )。我从未见过任何代码(在框架或其他方面)在 async 上具有 APM 包装器方法。一个。

因此，calling ReadAsync will result in calling BeginRead 因此任何限制都适用于两者。此外，由于 Stream不是线程安全的，也没有宣传为并发安全(略有不同)可以安全地假设你不能用 async 淹没它并发请求。