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