阻止 Boost Asio 工作线程
我正在开发一个基于 Boost::Asio 的网络服务器。
我有一个 IO 工作线程的 boost::thread_group，
当网络活动发生时，我用它来调用 boost::asio::io_service::run( ) ASIO 使用这些工作线程之一来处理活动（例如接受或接收）。
然后，我的应用程序会执行一些工作，可能是一些计算，可能是一些其他 IO（通过 boost），也可能是一些数据库活动。
我想知道在这些线程中完成上述工作的含义是什么。具体来说：
- 在 IO 线程上执行（可能是重要的工作）是否会导致
io_service有什么悲伤吗？
更具体地说：我应该考虑的任何其他问题。
I'm developing a network server based on Boost::Asio.
I have a boost::thread_group of IO worker threads which I use to call boost::asio::io_service::run( )
When network activity occurs ASIO uses one of these worker threads to process the activity (eg. Accept or Receive).
My application then does some work, possibly some calculation, possibly some other IO (via boost) and possibly some database activity.
I'd like to know what the implications are of doing said work within these threads. Specifically:
- Does carrying out ( possibly significant work ) on the IO threads cause
theio_serviceany grief?
And less specifically: any other issues I should be thinking about.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这实际上取决于你所说的悲伤是什么意思。在
io_service调用的处理程序中执行长时间运行的操作可能会阻止io_service调用其他处理程序。考虑一个最简单的示例，其中一个线程调用 io_service::run()。如果由异步操作调用的处理程序（例如async_read()）然后执行一些可能长时间运行的数据库操作，则其他未完成的异步操作将不会调用其处理程序，直到长时间运行的操作完成并且处理程序将控制权返回给 io_service。通常可以通过从多个线程调用 io_service::run() 并使用 strand 确保对使用共享数据的处理程序的独占访问来缓解此问题。不过，如果您的所有处理程序都执行一些长时间运行的操作，您可能需要研究替代设计。
It really depends what you mean by grief. Performing long running operations in a handler invoked by an
io_servicecan block additional handlers from being invoked by theio_service. Consider the simplest example with a single thread invokingio_service::run(). If the handler invoked by an asynchronous operation, sayasync_read()then performs some database operations that could be long running, additional outstanding asynchronous operations will not have their handlers invoked until the long running operation is complete and the handler returns control to theio_service.This is typically mitigated by invoking
io_service::run()from multiple threads, and using astrandto ensure exclusive access to handlers that used shared data. Though if all of your handlers perform some long running operations, you might need to investigate alternative designs.