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

From: Boris (boris_at_[hidden])
Date: 2005-04-22 17:37:32

Rob Stewart wrote:
> From: "Boris" <boris_at_[hidden]>
>> Caleb Epstein wrote:
>>> [...]
>>>> Also, how should the stream object behave in case of EWOULDBLOCK?
>>>> Set failbit? Even if we use a wouldblockbit, we still need to set
>>>> failbit,
>>>> as the only thing clear is that the operation was *not* successful.
>>>
>>> I would not recommend combining non-blocking I/O with streams, at
>>> least not in any way that becomes visible to the user of the stream.
>>
>> As far as I can see EWOULDBLOCK is just another reason for a stream
>> to fail. If you use << or >> with streams you must be prepared for
>> failure any way. The only difference with EWOULDBLOCK is that you
>> have to call << or >> again. However if I think about it I wonder
>> how reasonable non-blocking I/O streams are at all as they don't
>> support multiplexing - the application would need to call << or >>
>> again and again?
>
> How would the user level code know which insertion or extraction
> to repeat in an expression like this:
>
>   s << a << b << c << d;

Socket streams supporting non-blocking I/O would require the user to check 
the result of I/O operations. However this should already be done with 
today's std::iostreams. If s is eg. of type std::ofstream and a call to << 
fails you have the same problem, don't you?

Boris