Re: [boost] asio formal review begins

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-14 18:27:10

"Eugene Alterman" <eugalt_at_[hidden]> wrote

> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
> news:dnpe9q$vk6$1_at_sea.gmane.org...
>
> > Let me disagree with this.  There are cases when having multiple
threads,
> > each working in a synchronous way, is a better approach.  First, it's
much
> > more intuitive, and easier to debug.  Second, sometimes it's the only
way
> > to
> > achieve you goal, such as whan you can't (or don't want to) rewrite your
> > processing algorithm in asynchronous way.
> >
> > And when such a case arrives, it would be nice to have a clean socket
> > class,
> > without build-in asynchronisity.
>
> Hold on a second...
>
> Where has this perception that asio implements synchronous operations on
top
> of asynchronous come from?
> >From what I can see in docs and sources this does not seem to be the
case.
> Notice that demuxer::run() is not called in the tutorial synchronous
> samples.
>
> Synchronous operations are simply  implemented as regular blocking socket
> calls.

This is good.  Now what's left is to remove the dependency of the socket on
the demuxer.  Otherwise it's confusing: if demuxer is used, it has to be
used for some purpose, right?

Chris admitted that the socket class has built in features for asynchronous
processing.  This IMO is a conceptual overhead, and reminds of MFC's CWindow
class, which is always an activeX container.  Just in case.

Regards,
Arkadiy