Re: [asio-users] Multiple tcp acceptor in one program.
Brought to you by:
chris_kohlhoff
From: Igor R <boo...@gm...> - 2016-01-03 19:56:45
|
> Thanks for your reply. I'm defining ASIO_DISABLE_THREADS in my application now. > Does it mean that if I discard that macro and change no code, Asio will call > my handlers in other threads automatically? No. ASIO_DISABLE_THREADS means that Asio disallows operations that spawn internal threads, like async_resolve (if I'm not mistaken, such an operation will throw boost::asio::error::operation_not_supported exception). Even without this macro Asio won't parallelize your completion handlers, unless you invoke io_service::run() in multiple threads. Please, read the documentation for details: http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/tutorial/tuttimer5.html > Should I discard that macro? That depends on your requirements and limitations. Usually there's no reason to define this macro, unless your platform has restrictions with regards to threads. > If it's still single-threaded but having timer on every operation, are there any other benefits/pitfalls compared to multi-threaded application besides the waiting time for the timeout handler? There are 2 "levels" of "single-threadness": 1) One can invoke io_service::run() in one thread, but build w/o ASIO_DISABLE_THREADS. This allows Asio to spawn internal threads, when it needs to emulate asynchronous behavior, so all Asio features can be used. Still, it guarantees that all the completion handlers get invoked sequentially. So, from Asio user's point of view, the application is still single-threaded, in the sense that there's no need to provide any synchronization. 2) One can completely disable threads in Asio with the above macro. In this case, Asio guarantees that it doesn't spawn any threads, but you should assume that it may throw operation_not_supported exception under some circumstances. |