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