Re: [boost] asio review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-31 01:19:13

Hi Scott,

--- Scott Harris <harris_s_at_[hidden]> wrote:
<snip>
> I think that asio should be expanded to support a
> synchronous/reactive I/O as well as its current asynchronous
> support.  If the intent is to do so then I believe the library
> should be accepted.

Although I guess it might make your vote a "no", it is not
currently my intent to provide a reactive I/O interface as part
of asio.

Way back in the early days of asio I did investigate how to
implement a reactive socket-is-ready interface, but found that
an efficient and portable expression of this interface was not
available. The problem is not helped by platforms where there is
no reactive interface (Symbian is one example).

In fact, asio was born as an idea as the result of a
demonstration (based on ACE) that an efficient proactor could be
implemented in terms of a reactor.

Blocking synchronous I/O is of course still given first
class support (i.e. not implemented in terms of async I/O).

> Since performance is often a consideration in networking code,
> I do not think that synchronous support should be built on top
> of asynchronous capabilities.  My experience with asynchronous
> I/O vs synchronous I/O  (ACE_Proactor vs ACE_Reactor on
> Windows 2000 across 8 machines on a gigabit network in an
> application of 1000+ simulation objects) was that I needed to
> have > 200 pending I/Os for the Proactor to out perform the
> Reactor.  This implies that the problem space must include
> large number of non-dependent asynchronous reads and writes
> for asynchronous I/O to outperform a reactive approach.  My
> experience is that most applications do not have that many
> parallel I/O operations.

I am somewhat surprised, and intrigued, by these results, given
that you were running on Windows. Which reactor implementation
were you using - WFMO or select? I would guess select if you had
to handle > 200 pending I/O requests.

I ask because, after adding the custom allocation support during
the review, a test run on Windows comparing asynchronous to
synchronous I/O for a single socket (meaning only one pending
I/O operation at a time) showed negligible difference in
performance between them.

I intend to spend some time developing a more comprehensive set
of performance tests (there are some simple TCP throughput tests
in CVS but not included in the boost proposal distribution). It
sounds like it would be worthwhile developing equivalent tests
using ACE's reactor classes for comparison. I'll also write some
tests that use select or overlapped I/O directly to measure the
abstraction penalty of asio.

Cheers,
Chris