On Jul 9, 2020, at 10:49 AM, Richard Hodges via Boost-users
It's not equivalent because in the case of one thread per io_context, the completion handler of asynchronous operations will always be invoked on a known thread. Therefore concurrency protection is not a concern.
If you use the executor of a thread_pool, there is no guarantee which thread will invoke the completion handler, and no guarantee that two completion handlers will not touch the same user object. This argues for the use of asio::strandasio::thread_pool::executor_type as the executor to be associated with the completion handler (or set as the default executor of related io objects).
It seems that my original email was a bit misleading and implied that I was comparing (many threads, many asio::io_context objects) with asio::thread_pool. In fact, I’m trying to compare (many threads, one asio::io_context object) with asio::thread_pool. From what you’ve said above, it looks like (many threads, one asio::io_context object) and asio::thread_pool are logically equivalent. Can you speak to any performance differences between these (or point to reference material which touches on this)?
Is there a use case or is this a question out of curiosity?
Mostly out of curiosity. I’ve found myself repeatedly writing code where a single asio::io_context is dishing out tasks to many threads, and am wondering if asio::thread_pool is a drop-in replacement for manually setting up a thread pool and calling asio::io_context::run from each thread. -Ani