Re: [boost] reactor versus proactor

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-22 16:20:16

HI Arkadiy,

--- 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
> 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