16

I'm trying to clear up some confusion I have. I stumbled over boost::asio::thread_pool and I thought that one could use to somehow automatically combine boost::asio::io_context and boost::thread::thread_group like is often suggested (here or here). It appears that this asio-specific pool can be used to post tasks to but, on the other hand, some networking types like resolver need to be passed an object io_context as a constructor parameter which thread_pool isn't and doesn't derive from.

screwnut
  • 1,367
  • 7
  • 26

2 Answers2

5

Say you have a single io_context object, named ioc.

You can create several threads, and call ioc.run() in each one of them. This is a blocking operation that blocks on epoll/select/kqueue. Note that ioc is shareable, and by calling ioc.run() in several threads, they implicitly belong to a thread pool to be used by ioc. Let's call this pool io_threadpool.

Now create a separate pool of threads called compute, that do other things. Here is what is possible:

  • You can use ioc in threads from both pools (except for a few, like restart(), which require that ioc is not actively running).

  • You can make sync I/O calls from any thread.

  • You can invoke an async call like async_read( ..., handler) from any thread. However, the handler is only invoked in one of the io_threadpool threads.

  • You can dispatch tasks in either thread pool, but if the task is not going to do any I/O, I expect it to be more efficient to dispatch it in the compute pool, because the system doesn't have to wake up the epoll()/kqueue()/select() call on which it is blocked.

Joel Bodenmann
  • 2,152
  • 2
  • 17
  • 44
Sriram Srinivasan
  • 1,255
  • 17
  • 16
2

You should post your io_context.run() into the thread_pool.

Joel Bodenmann
  • 2,152
  • 2
  • 17
  • 44
user2709407
  • 460
  • 1
  • 4
  • 11