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

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-04-22 12:55:22

On 4/22/05, pedro.lamarao_at_[hidden] <pedro.lamarao_at_[hidden]> wrote:
> Caleb Epstein wrote:
>
> > If non-blocking I/O were a possibility, I don't think throwing
> > exceptions on EWOUDBLOCK would be performant.
> 
> I don't think it is necessary to throw an exception from the stream to
> signal it, for the same reason the stream can signal other kinds of
> errors without throwing exceptions. The standard basic_ios base class is
> even nice enough to offer the exceptions(iostate) "property" for you to
> choose if you want or don't want exceptions to be thrown. Nothing new here.

But from my reading of your code, you explicitly throw whenever the
system calls return -1.  Please correct me if I am wrong.

> I believe a non-blocking mode is possible for std::iostream, but I'm
> unsure of how... elegant would it be to use it.

I'm not suggesting we implement non-blocking iostreams (I'll leave
that to Jonathan :-), but the lowest level basic_socket implementation
ought to support it.  I don't see how it does in your implementation.

> But should we offer the possibility for the user to set socket options,
> or merely offer a blocking(bool) method?

At the basic_socket level, all socket functionality should be
accessible.  Its all there for a reason, so if you leave something
out, someone is guaranteed to complain.

> 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. 
I'm just advocating that the lowest level API should provide this
functionality.  Streams operate at a higher level.

-- 
Caleb Epstein
caleb dot epstein at gmail dot com