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