Boost logo

Boost :

From: Boris (boris_at_[hidden])
Date: 2005-04-27 18:12:30

Scott Woods wrote:

Hi Scott,

> [...]
>> If I understand correctly your socket streams support blocking I/O.
> However
>> I/O methods are guaranteed to return immediately as data is copied
>> to the so-called "application zone" where it waits until it is sent
>> to the
> network?
> Yes to the first question (i.e. blocking I/O).
> Not clear on what you were asking in the second. I'll try the shotgun
> approach
> and hope I hit something :-)

I try again, too. :-) What I wanted to say is that the blocking I/O methods
of your socket stream always return immediately. They block but don't need
to wait because they just copy data to another application buffer. When the
library user calls your operator<< he knows the call will return immediately
and not after eg. 10 seconds. Is this correct?

> [...]
> My approach to input is (inevitably? ;-) completely different. There
> are no "operator>>( stream &, application_object & )"'s to match the
> output operators; the design is asymmetric. This is for the simple
> reason that a function with such a signature implies blocking; it
> must wait for
> potentially
> multiple network reads to complete the application_object. The design
> is fully async.

If there is no operator>> don't you think you make socket streams less
useful for library users? Isn't the idea of socket streams that library
users who are familiar with the interface of iostreams can start sending and
receiving data on the network without knowing too much about the details? If
you write "std::cin >> a;" you know it will stop your program until
something is entered. I'd think it makes sense if socket streams behave


Boost list run by bdawes at, gregod at, cpdaniel at, john at