From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-22 16:20:16
--- Arkadiy Vertleyb <vertleyb_at_[hidden]> 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
> 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
> 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
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
- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk