What's the difference between asio::io_context and asio::thread_pool?

Question

Whats the difference between an asio::thread_pool and an asio::io_context whose run() function is called from multiple threads? Can I replace my boost::thread_group of threads that call io_context::run() with an asio::thread_pool? Or do I need somewhere an io_context?

Update

When I use asio::thread_pool, do I still need an io_context to use sockets, timers, etc? Both thread_pool and io_context are an asio::execution_context. However, the docs say on io_context that it "Provides core I/O functionality". Do I lose these if I only use an asio::thread_pool without an io_context?

Answer 1

A threadpool implicit runs all the tasks posted on it (until it's stopped).

An io_service doesn't assume anything about the threads that will run it: you need to make sure you do that, and you're free to decide whether you run it on multiple threads, one thread, or even a mix (like one thread at at time, but from multiple threads?).

Further notes:

• handle exceptions emanating from io_service run/poll members (Should the exception thrown by boost::asio::io_service::run() be caught?)
• if you run an io_service on multiple threads, make sure you understand thread-safety of the service objects you use (see Why do I need strand per connection when using boost::asio?)
• If you know how many threads will run your service, consider supplying the concurrency hint on construction (https://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/overview/core/concurrency_hint.html)
• io_service can be restarted (after a reset()). asio::thread_pool not so much (see [search is dead atm], compare with asio::io_service and thread_group lifecycle issue)
• The threads governed by asio::thread_pool are "opaque": you cannot control how they're created. Which is a bummer if you need to e.g. initialize a third party library per thread or wanted to use Boost Thread with interruption_points etc.