[boost] Re: Re: Re: Re: Re: Re: (Another) socket streams library

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 
similarly?

Boris