Boost logo

Boost :

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


"Christopher Kohlhoff" <chris_at_[hidden]> wrote

> I've been thinking about these issues since your email. My
> feeling is that a use case doesn't have to become very
> complicated for the asynchronous operations to be beneficial.
> But where a developer's needs are simple enough, I suspect
> that's also when they are going to want to use an
> iostreams-based interface.

Your assumption seems to be that only simple problems have to be solved
synchronously, but once the problem is complicated enough, asynchronous
approach is definitely superior.

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.

> Since iostreams basically enforce
> synchronous operation, this seems like a sensible place to hide
> the demuxer and asynchronicity away.

Personally, I wouldn't like it to be "hidden away". I would like it to be
"removed" for such cases.

Regards,
Arkadiy


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk