From: Boris (boris_at_[hidden])
Date: 2005-04-22 13:54:23
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
>> 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?
> I'm just advocating that the lowest level API should provide this
> functionality. Streams operate at a higher level.
After following most of the discussions I think this is broad consensus.
That's why http://www.highscore.de/boost/net/packages.png looks like it