"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:dnpe9q$vk6$1@sea.gmane.org...
Let me disagree with this. There are cases when having multiple
"Eugene Alterman" <eugalt@verizon.net> wrote 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