"Peter Dimov" <pdimov@mmltd.net> 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