[asio] some design questions
Hi. I'm looking at the Design page of the asio docs (http://tinyurl.com/2b5afn) and several questions come to mind: 1. The "Proactor" page has Advantages/Disadvantages section, but it doesn't specify in comparison to what (advantages and disadvantages are always compared to something). I'm getting the impression that it's compared to the Reactor approach. Is this correct? 2. The "Platform-Specific Implementation" page notes that when using select/epoll/kqueue, demultiplexing is performed in one of the threads that calls boost::asio::io_service::run(). I assume that when this thread is awaken to perform some task, one of the other threads that called run() on the same boost::asio::io_service takes it position as waiting on select/epoll/kqueue. Is this correct? 3. The "Platform-Specific Implementation" page also notes that "An additional thread per io_service is used to emulate asynchronous host resolution. This thread is created on the first call to either boost::asio::ip::tcp::resolver::async_resolve() or boost::asio::ip::udp::resolver::async_resolve()." So I guess that if I resolve() rather than async_resolve(), then no thread is created, and the actual resolving is done in the thread that called resolve()? I think all these notes would be a good addition to the docs. Thanks.
Yuval Ronen wrote:
1. The "Proactor" page has Advantages/Disadvantages section, but it doesn't specify in comparison to what (advantages and disadvantages are always compared to something). I'm getting the impression that it's compared to the Reactor approach. Is this correct?
Actually it is compared to both the Reactor and thread-per-connection approaches.
2. The "Platform-Specific Implementation" page notes that when using select/epoll/kqueue, demultiplexing is performed in one of the threads that calls boost::asio::io_service::run(). I assume that when this thread is awaken to perform some task, one of the other threads that called run() on the same boost::asio::io_service takes it position as waiting on select/epoll/kqueue. Is this correct?
Yes, that's correct.
3. ... So I guess that if I resolve() rather than async_resolve(), then no thread is created, and the actual resolving is done in the thread that called resolve()?
That's also correct. Thanks for the suggestions. I will add the clarifications to the documentation. Cheers, Chris
Christopher Kohlhoff wrote:
Yuval Ronen wrote:
1. The "Proactor" page has Advantages/Disadvantages section, but it doesn't specify in comparison to what (advantages and disadvantages are always compared to something). I'm getting the impression that it's compared to the Reactor approach. Is this correct?
Actually it is compared to both the Reactor and thread-per-connection approaches.
One of the advantages there is "Portability". Is the proactor approach more portable than reactor or thread-per-connection? I might even go further and say that portability is a non-issue because it's a pre-condition. All approaches are required to be portable, and an approach that isn't, is automatically discarded. So it's "obvious" that all finalists are portable, and that includes reactor and thread-per-connection. Isn't it?
3. ... So I guess that if I resolve() rather than async_resolve(), then no thread is created, and the actual resolving is done in the thread that called resolve()?
That's also correct.
I'm a little uneasy by the fact that even is such case I need an io_service. If I'm not doing asynchronous I/O, why would I need an asynchronous service manager? This topic might have been discussed during the review, which I'm sorry I didn't follow, or it might be already explained in the docs. I'd appreciate any link.
participants (2)
-
Christopher Kohlhoff -
Yuval Ronen