Re: [boost] asio formal review begins

From: Eugene Alterman (eugalt_at_[hidden])
Date: 2005-12-16 14:08:53

"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message 
news:dnq31k$f1f$1_at_sea.gmane.org...
> My problem with the current approach is that synchronous operations seems 
> to
> be viewed as second-class citizens.  I understand that this is caused by 
> the
> fact that asio is about the asynchronous IO.  But asio is presented as the
> "best C++ networking library around", and in networking both synchronous 
> and
> asynchronous approaches are used, and neither is superior for all possible
> cases.
>
> Consider "Patterns for concurrent and networked objecs" by D. Schmidt, at
> al.  Quite a few patterns described there are related to the synchronous
> processing.

I just want to point out (hopefully without getting off topic too much) that 
there is an important difference between  what you mean by  'synchronous' 
and the way this term is usually used in this context (and in particular  in 
the publication you are mentioning).

By 'synchronous' you seem to mean *blocking* synchronous i/o while in those 
patterns it is understood as synchronous i/o event demultiplexing and 
handling, meaning that a synchronous  i/o operation is issued only if there 
is a ready event and the operation would not block. As a matter of fact this 
is the way asynchronous operations are emulated in asio on platforms that 
don't support them directly.

As has been already pointed out blocking i/o operations is a bad option for 
critical high performance servers since they waste thread resources. That is 
why you won't find them in the book - just take a look at the Half Sync/Half 
Async pattern and compare it to your implementation.

As in general, you may use whatever approach you come up with as long as it 
suits your particular needs, but providing solutions that encourage best 
practices is what design patterns are for.

And asio provides a solution based on one of such patterns (Proactor) that 
happens to be asynchronous.