boost.asio 和文件 i/o 有什么关系？

Question

我注意到 boost.asio 有很多涉及套接字、串行端口和各种非文件示例的示例。Google 并没有为我提供太多信息来说明 asio 是否是执行异步文件 I/O 的良好或有效方法。

我有大量数据想要异步写入磁盘。这可以通过 Windows（我的平台）中的本机重叠 io 来完成，但我更喜欢有一个独立于平台的解决方案。

我很好奇如果

1. boost.asio 有任何类型的文件支持
2. boost.asio 文件支持对于日常文件 I/O 来说足够成熟
3. 是否会添加文件支持？这方面的前景如何？

Answer 1

boost.asio 有任何类型的文件支持吗？

从（我认为）Boost 1.36（包含Asio 1.2.0）开始，您可以使用 [boost::asio::]windows::stream_handle 或 windows::random_access_handle 来包装 HANDLE 并对其执行异步读写方法内部使用 OVERLAPPED 结构。

用户 Lazin 还提到了 boost::asio::windows::random_access_handle 可以用于异步操作（例如命名管道，还有文件）。

boost.asio 文件支持对于日常文件 I/O 来说是否足够成熟？

由于Boost.Asio本身现在已经被广泛使用，并且其实现内部使用了重叠IO，所以我会说是的。

是否会添加文件支持？这方面的前景如何？

由于网上没有找到路线图 阿西奥 网站上，我想说 Boost.Asio 不会再增加此功能。尽管贡献者总是有机会向 Boost.Asio 添加代码和类。也许您甚至可以自己贡献缺失的部分！:-)

Answer 2

Linux 上的 boost::asio 文件 i/o

在 Linux 上，asio 使用 epoll 检测套接字/文件描述符是否准备好读/写的机制。如果您尝试在 Linux 上的常规文件上使用 vanilla asio，您将收到“不允许操作”的异常，因为 epoll 不支持 Linux 上的常规文件.

解决方法是将 asio 配置为使用 select Linux 上的机制。您可以通过定义来做到这一点 BOOST_ASIO_DISABLE_EPOLL. 。这里的权衡是 select 往往比 epoll 慢 如果您正在使用大量打开的套接字。定期使用打开文件 open() 然后将文件描述符传递给 boost::asio::posix::stream_descriptor.

Windows 上的 boost::asio 文件 I/O

在 Windows 上您可以使用 boost::asio::windows::object_handle 包裹一个 Handle 这是通过文件操作创建的。看 例子.

Answer 3

ASIO 在 Windows 上支持重叠 I/O，并且支持良好。在 Unix 上，这个想法已经停滞不前，原因如下：

• 文件通常位于同一物理设备上，最好按顺序访问它们。
• 文件请求通常完成得非常快，因为它们在物理上很接近。
• 文件对于完成程序的基本操作通常至关重要（例如必须在进一步初始化之前读取其配置文件）

一个常见的例外是直接向套接字提供文件。这是一个常见的特殊情况，Linux 有一个 核函数 为你处理这个问题。再次否定使用异步文件 I/O 的理由。

简而言之：ASIO 似乎反映了底层操作系统设计理念，大多数 Unix 开发人员忽略了重叠 I/O，因此该平台不支持它。

Answer 4

boost::asio::windows::random_access_handle 是最简单的方法，如果你需要一些高级的东西，例如异步 LockFileEx 或其他东西，你可以扩展 asio，添加你自己的异步事件。 例子

Answer 5

Linux 有一个 asio 库，对于这项工作来说，它并不比 Windows API 更难使用（我已经使用过它）。两组操作系统都实现相同的概念架构。它们在与编写优秀库相关的细节上有所不同，但还没有达到无法为两个操作系统平台提供通用接口的程度（我已经使用过一个）。

基本上，所有类型的异步文件 I/O 都遵循“Fry Cook”架构。这就是我在阅读操作中的意思：我（处理线程）走到快餐柜台（OS）并要一个芝士汉堡（一些数据）。它给了我一份订单票（一些数据结构）的副本，并在后面向厨师（内核和文件系统）发出一张票来烹饪我的汉堡。然后我坐下来或看手机（做其他工作）。后来，有人宣布我的汉堡准备好了（向处理线程发出信号），然后我收集食物（读取缓冲区）。