On Jul 9, 2020, at 10:49 AM, Richard Hodges via Boost-users <boost-users@lists.boost.org> wrote: > 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::strand<asio::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 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
