c++ - 手动驱动非阻塞原生句柄的最基本的 Asio 执行上下文是什么？

Question

假设我有一个现有程序，现有主循环以“传统方式”完成，我可以注册以在文件描述符可读时收到通知，等等。为了这个问题的目的，我们假设我们不' 想要修改此循环以使用 Asio。

然后我似乎可以采用，例如，Asio 数据报套接字，将其设置为 native_non_blocking()，监视其 fd 以获取读取事件，然后通过执行“阻塞”来对此类事件作出 react "receive_from() 调用并期望它们通过 error_code 返回相当于 EAGAIN 或 EWOULDBLOCK 的内容。写入也是如此。

(让我们忽略这是否是 Asio 的“精神”。这不是问题的真正目的。)

那么我的问题是，要执行此操作我需要提供的最低执行上下文是什么？似乎我真的不需要 io_context(例如，在 Linux 上，它会为 epoll、signalfd 和 timerfd 打开一些额外的 fds)因为我永远不应该使用 它。似乎我真的不想要 system_context 或 thread_pool 因为我真的不想在其他线程上运行任何东西。

是否有一些适合此处的预定义“相同线程”上下文？如果现在，人们将如何构建这样的东西？或者，Asio 套接字上公开的 API 是否仍然“有时”实际上在幕后使用 io_context 的功能，即使在制作“阻塞”receive_from() 或 send_to() 在一些隐藏的微事件循环中调用非阻塞套接字(如果是，为什么)？

Answer 1

Is there some pre-defined "same thread" context that would be appropriate here?

io_context 只提供上下文，不包含任何有关线程使用它的内容。因此

boost::asio::io_context io;
io.run();

已经是你的最小上下文。

您的困惑似乎来自于 run() 打算提供事件循环，这看起来像是阻塞行为。有两种方法:

• 不要在任何地方调用 run()(这会限制您的选择，但如果您确实只是发誓要使用 native 后门(native_handle() 和 friend ) ) 你不应该关心。

• 将 run_one() 或 poll_one() 集成到您的事件循环中，然后开心就好。这允许您使用构建在 io_context 抽象及其执行程序上的全部 Asio 服务，同时您显然也可以使用后门程序¹。

旁注:不要忘记正确处理来自 {run,poll}[_one]()

的异常

---

¹ 风险由您自行承担，因为结合它们意味着您了解对您将要支持的所有平台的影响