提升 asio 服务队列深度和策略

Question

我了解正在运行的 asio 服务就像一个队列，我可以使用它来发布线程将按顺序执行的任务。但是，与任何队列一样，我想也有限制。是否可以为 asio 服务设置此限制？是否可以设置队列满时遵循什么策略（即阻塞、非阻塞等）？

更新

假设我有一个运行 asio::service 的线程和一个每 10 毫秒向该线程发布一个任务的计时器。任务接收绑定到一个方法调用，这将使线程休眠 100 毫秒。因此，我有一个计时器每秒向一个线程发布 100 个任务，该线程每秒能够执行 10 个任务。很明显，这种情况会有所不同。然而，在处理队列时，通常有方法来衡量队列深度（100？1000？入队的帖子等）或指定发送方在队列满时应该遵循的策略（即它应该等待还是应该丢弃请求并继续？）。我的问题是如何在 asio::service 中设置这些功能？

Answer 1

Asio 不提供控制内部数据结构的策略。但是，它确实提供了处理程序分配的挂钩：asio_handler_allocate 和 asio_handler_deallocate。应用程序可以使用这些挂钩来限制未完成的异步操作的数量，以及定义达到用户指定限制时的行为。

有几个关键点需要考虑：

• asio_handler_allocate 应该返回一个有效的内存块或者抛出一个异常。如果从asio_handler_allocate 抛出异常，它将通过io_service::post() 等调用继续展开堆栈。因此，对于达到最大值时的非阻塞行为，抛出可能是唯一的选择。
• 考虑对组合操作的影响，例如async_read，其中asio_handler_allocate 和asio_handler_deallocate 可能会被多次调用。如果抛出异常，线程的堆栈将至少展开到调用io_service::run 的位置。如果发生阻塞，则有可能使所有为反应器服务的线程都被阻塞，从而基本上阻止了所有异步作业的完成。

这是来自 Boost.Asio 示例的分配 example，显示了用于处理程序的内存池。

Answer 2

我不知道。至于您的示例，最好在io_service 的线程中设置一个计时器，该计时器执行长时间运行的任务并在工作完成后重新安排自己的时间。否则你永远不会清理你的队列。如果你想要一个具有良好时序约束的实时系统——通用操作系统/编程和 boost.asio 都不能胜任这项任务。