std::boost::asio::post / dispatch 使用哪个 io_context?
Posted
技术标签:
【中文标题】std::boost::asio::post / dispatch 使用哪个 io_context?【英文标题】:Which io_context does std::boost::asio::post / dispatch use? 【发布时间】:2018-09-22 16:27:44 【问题描述】:在使用 boost::asio 1.66 时,我在文档中读到 boost::asio::io_context::post
已被 boost::asio::post
弃用,boost::asio::io_context::dispatch
也是如此。因为在他们之前是io_context
的成员函数之前,当然处理程序需要在一些io_context
的上下文中执行,即executor
我的问题是:
boost::asio::io_context::post 最简单的重载如何知道使用哪个io_context
即executor
?
template< typename CompletionToken> DEDUCED post(CompletionToken && token);
的文档指出
通过执行get_associated_executor(handler)获取handler关联的executor对象ex。
但是get_associated_executor
的文档也没有让我清楚。我的猜测是由于 Template 参数推导,它可以在当前执行的处理程序中以某种方式获取它,但我想确保并且,如果我在 a 之外调用 post
这还不够boost::asio 处理程序。
【问题讨论】:
【参考方案1】:文档的核心在associated_executor
trait:
get()
如果 T 具有嵌套类型 executor_type,则返回 t.get_executor()。否则返回 ex。
executor_type
如果 T 有一个嵌套类型 executor_type,T::executor_type。否则执行者。
如果您的处理程序类型¹具有嵌套的 executor_type
类型,则假定调用 token.get()
将返回要使用的正确执行程序。
如果你在没有指定执行器/执行上下文的情况下传递一个普通的可调用对象,你将获得一个默认构造的执行上下文实例:boost::asio::system_executor
。
这样做的目的是使用自定义处理程序类型实现 DoTheRightThing。例如。如果您在链上发布某些内容,则处理程序将被包装在特定于链实现的类型中。 associated_executor
trait 和同上的 get_executor()
成员函数将协调以指向该链的执行器。
¹ 或任何标记,以防您的调用模型不同,例如 yield 上下文
【讨论】:
我猜“系统执行器代表一个执行上下文,允许函数在任意线程上运行。”意味着,任何线程等待任何io_context.run()/run_once()
等?
我可以自己回答:安排函数在未指定的系统线程池上运行”。我想我想指定执行者,感谢您寻找的指针。
是的。通常,您希望在边缘指定执行者。在组合操作中,您想让系统推断出关联的执行器,以便像 strands 这样的东西神奇地工作
我不喜欢魔法,尤其是在锁定并发代码方面。猜猜这是 boost::asio 设计师的一次不错的尝试,但我担心他们做得过火了。
我听到了。然而,这不是一个可以通用解决的微不足道的问题。您应该意识到这也是标准库中提出的新设计。无论如何,除非您打算编写库级代码(就像组合操作一样,您希望在基因上表现并与来自另一个库的任何自定义处理程序调度相结合),否则您不必了解内部结构。如果没有,只需发布给特定的执行者就足够了。以上是关于std::boost::asio::post / dispatch 使用哪个 io_context?的主要内容,如果未能解决你的问题,请参考以下文章