From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-14 11:43:44
"Peter Dimov" <pdimov_at_[hidden]> wrote
> Arkadiy Vertleyb wrote:
>
> > 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.
>
> Even if this is the case, is it the responsibility of a library that
offers
> Asynchronous I/O as a primary focus to supply a clean socket class that
has
> nothing to do with async I/O?
In general, no.
But when the library also offers syncronous operations, then yes, I would
like this to be implemented cleanly, rather than having asyncronous stuff,
even if hidden underneath.
Also, let's consider a broader picture. Network programming consists of
both synchronous and asynchronous approaches, sometimes mixed together. One
can start with one approach, and then switch to another.
Maybe I got a wrong impression, but to me it looks like asio is offered (or
perceived) as something like Boost Networking Library. And as such, I would
expect clean sockets from it. Otherwise, who will provide them? Do we
expect another Socket class to be reviewed any time soon?
Regards,
Arkadiy