[boost] Re: (Another) socket streams library

From: pedro.lamarao_at_[hidden]
Date: 2005-04-22 17:05:42

Caleb Epstein wrote:

>>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.

That's inside the basic_socket class; the point there is to support some
kind of easy, low level socket operation. Thus, let's throw instead of
constantly checking for (-1).

But inside the streambuf, all exceptions are caught.
I haven't worked much more on this aspect of the streambuf yet, but here
the point is never to throw.

Even if we want exceptions to be thrown, that should be handled by
basic_ios -- setting failbit. At least, that's what's currently on my mind.

>>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.

It doesn't, because I didn't bother to add a wrapper to fcntl().
That's easy to do, though, and would be consistent with the purpose of
the basic_socket class.

But you can always pass MSG_DONTWAIT as the flag parameter of the
receive and send methods. That will provide you with a non-blocking call.

>>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.

Agreed.
The point of the exposed "socket" class is to provide an easy entry
point to what I would call "hybrid" networking code -- so that someone
can easily substitute raw system calls to use "socket" objects without
much code rewriting.

--
 Pedro Lamarão