Boost logo

Boost :

From: Pedro Lamarão (pedro.lamarao_at_[hidden])
Date: 2005-08-03 17:58:12


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

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