Re: [boost] asio formal review begins

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-14 16:32:35

"Jeremy Maitin-Shepard" <jbms_at_[hidden]> wrote

> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:
>
> > [snip]
>
> > I would expect both asio and a stream API to be layered on top of
low-level
> > socket API.  This socket API should wrap the platform dependency, but
> > otherwise provide pretty much the same capabilities as current C socket
APIs
> > provide, with minimum overhead.
>
> The key problem with that approach is that a `thin' wrapper over the
> platform APIs is basically useless for implementing asynchronous
> operations, because asynchronous operations must be implemented in
> widely different ways on the different platforms.
>
> For synchronous operations, it happens to be the case that every
> platform provides basically the same interface, so at least a portable
> (but not necessarily very good) interface can be created through only a
> thin wrapper.

Then maybe it would make sence to define this kind of API for synchronous
operations, while asio encapsulates asynchronous IO using a higher-level
abstraction.  The socket class would be cleanned from the asynchronous
stuff, and used by both asio and synchronous API.

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 think a little refactoring  might lead to a better solution than trying to
add synchronous operations on top of existing asio.

Regards,
Arkadiy