HI Arkadiy, --- Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
This is a question to networking gurus, and is on the edge of being off topic, but I am asking it here because I hope it will help me to better understand rationale behind the asio design...
As was stated before, asio is based on the proactor pattern. This pattern is known for its scalability, but is difficult to port since it's based on asynchronous calls which are implemented differently (or not implemented at all) on diferent OSs.
Since asio has a proactor implementation layered on top of a select reactor, I believe it can be just as portable as select is.
OTOH, reactor (the one based on select) seems to be easily portable, and also scalable, but its only real problem is that it doesn't utilise threads, and so it can't take an advantage of multi-processor systems.
So my question is, isn't this drawback easily remedied by just placing select-ed sockets into a queue, and having multiple threads (from a thread pool) pick them up and performing the work? Wouldn't this provide comparable performance on multiple processors, with much better portability, than proactor?
The select reactor and thread pooling implementation inside asio could use some improvement to do just as you describe. The portable ACE-based proactor described at http://www.terabit.com.au/articles.php (from which asio derives many ideas) does this, I believe. Unfortunately the reactor pattern is not as portable as you might think: - On Windows, select is much less efficient than overlapped I/O. An alternative reactor implementation using WaitForMultipleObjects limits you to 64 handles per call. - There are operating systems that provide asynchronous I/O without supporting reactive I/O. Symbian is an example. So in summary, I think proactor is the most portable choice because it can be efficiently implemented in terms of a reactor, but can use native asynchronous I/O when that is more efficient, or indeed the only viable option. Cheers, Chris