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

Question

我一直在尝试实现一个支持ReadAsync 和WriteAsync 的Stream，并且考虑到documentation 的简洁性，我很难理解如何正确地做到这一点。具体来说，关于流的光标位置。关于旧的 BeginRead 函数，here 和 here 也提出了类似的问题。该函数的文档似乎表明，在任何挂起的异步操作完成之前，不应再次调用 BeginRead。

鉴于 BeginRead 现在已弃用 no longer recommended for new development 和 Stream 可能已进行了重大更改以实现新的 Async 功能，事情再次不明朗。 （编辑：通常这种警告意味着新函数是直接实现的，旧函数调用新函数，只是为了向后兼容而仍然存在，但这里的情况似乎并非如此）。

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

1. ReadAsync 和 WriteAsync 必须获取当前光标位置以供操作使用，并在返回 Task 之前将其更新为操作完成（或根本不更新），或者
2. 在完成之前的所有异步调用之前，不能调用 ReadAsync 或 WriteAsync。

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

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

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

Answer 1

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

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

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

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

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