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

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2005-05-11 14:48:36

Nathan Myers wrote:

> What do we need from this boost-nonblocking-socket-streambuf?  At
> minimum, we need to see what it has in its buffer (i.e. begin()/end()), 
> and we need for that buffer to grow as large as necessary until we 
> can hand it to some library to be drained.  (Maybe it's backed by a 
> std::deque<char>.)  Beyond that, it would be nice for it to abstract 
> the calls to open and jimmy the socket.  None of this is rocket
> science.

I am concerned that this is only compatible with algorithms where the
total amount of data to be read in a single operation is small enough to
fit into a reasonable amount of buffer memory, and that this encourages
dubious code by having very different interfaces for the very similar
operations of /examining the data/ and /examining the data and removing
the data from the buffer/.

What do you think about an alternate scheme that requires the parser to
be aware of the non-blocking interface of a stream?  Add a would-block
condition to the streambuf that is like EOF except it just means you're
out of data, and add a mechanism for unlimited (and efficient)
push-backs.  Perhaps the istream might translate this into a blockbit
flag and a mechanism to do this rollback automatically when extraction
fails due to blockbit.

Aaron W. LaFramboise