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

From: Boris (boris_at_[hidden])
Date: 2005-04-25 18:31:43

Rob Stewart wrote:
> [...]
>> I was under the false assumption that "s << a" either completes
>> successfully or fails completely. But you are right: If a part of
>> object a is sent we don't know. Thanks for jumping in! I agree now
>> that socket streams can only support blocking I/O.
>
> It is possible to get the condition you describe, too, But my
> example was a typical insertion expression in which multiple
> insertions are done on one line and the result isn't checked
> until after:
>
>   s << a << b << c << d;
>
> Ignoring the possibility that any of those insertions only
> partially completed because of UDT insertion operators, for
> example, you don't know which insertion (of a, b, c, or d)
> failed if the result of the expression is false (i.e., if
> s.good() is false).

I understand your point but still think this is true for any stream. There 
might be other ways to find out where insertion breaks (like in your example 
with a file) but then you leave of course the stream interface and don't use 
standard methods.

However I withdraw the idea of non-blocking I/O support in socket streams 
anyway as we can't know with the standard interface if "s << a" fails 
partially.

> Note that you can use unformatted input/output functions on
> streams.  Those could reasonably offer async I/O since they
> effectively just forward to the underlying streambuf for I/O.
> However, you still have to figure out how to report EWOULDBLOCK.

I don't know how many developers require non-blocking unformatted I/O 
functions. I think most developers like streams because of code like "s << a 
<< b << c << d". It's probably not worth the effort to support non-blocking 
unformatted I/O functions. If anyone thinks differently he should tell us 
now! :)

Boris