"Christopher Kohlhoff" <chris@kohlhoff.com> 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