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.