Edward Diener wrote:
Pedro Lamarão wrote:
Aaron W. LaFramboise wrote:
Asynchronous socket support: Finding a way to represent asynchronosity, that works with diverse coding styles, meshes with existing interfaces, and doesn't monopolize control flow away from foreign components, is the most important feature needed for a standards-track sockets proposal.
Please do not consider submitting this library for review without this. I expect that the work of creating this interface, in a form that addresses everyone's diverse needs, will dwarf the amount of effort required to create a synchronous socket streambuf. This is not a feature that can be tacked on later: it is essential to the design.
There are many networking applications where synchronous operation is quite suficient. Most of these can use threading to deal with concurrent connections satisfactorily.
I don't think it's particularly useful to hold a library that fulfills these needs in order to achieve the holy grail of C++ IO. One thing at a time.
Any networking library which does not have non-blocking asynchronous support for network I/O is, IMO, doomed to general non-use. But go ahead and create one if you like and see how many end-users adopt it for their networking needs.
I'm sincerely fascinated by this comment, which I feel represent how almost everyone in these networking threads feel. I must be absolutely ignorant in what constitutes a performant networking application, if multiple threads blocking on IO is a design doomed to general non-use by those writing multi-session applications. Can you explain to me what is fundamentally wrong with this model, and how the use of asynchronous primitives or the non-blocking mode is so vastly superior? I would sincerely like to know, because I've been writing those for some time, and, though our clients aren't complaining, perhaps I could be delivering more. -- Pedro Lamarão