Boost logo

Boost :

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

"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at