Hi Scott, --- Scott Harris <harris_s@ociweb.com> 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