Hi Nathan, ----- Original Message ----- From: "Nathan Myers" <ncm@cantrip.org> To: <boost@lists.boost.org> Sent: Wednesday, May 04, 2005 3:55 PM Subject: Re: [boost] Re: (Another) socket streams library [snip]
The catch (for me) is that such a call is still blocking. The thread that performs the call (operator<<) must wait for the complete object off the stream.
Not quite. The idea is that operator>> will operate on known text obtained without blocking and without EWOULDBLOCK. I don't recall how one can tell how much is in an incoming socket buffer (nothing
ioctlsocket( socket, FIONREAD, &available ) Yep - non-portable.
very portable, in any case), but it is easy enough to tell if there's at least _something_ there: do a select() with a zero timeout, and see if it says it's ready. (More likely your regular select() loop woke up and told you so.) If so, trigger an underflow() (with sgetc(), say), which will get up-to-a buffer-full. (Make sure the buffer is at least as big as the OS's.) After there's text in the buffer, you can decide if it's enough to merit calling whatever is supposed to extract and operate on it.
I assume the caller (of operator>>) is "paused"?
A special streambuf can provide direct access to the buffer contents, too, so you can check if the input really is terminated. If it's not
What constitutes "really is terminated"? Are you parsing the stream in some way?
terminated, you can go back to sleep and wait for more (and for other events too). If it's terminated, you hand it over, and they process it, none the wiser. Of course they have to be willing to stop reading before EOF -- or at least not mess up their internal state if they are fed an EOF at an agreed-upon spot by our complicit streambuf. (We can clean up any fail/eof/bad flags after we get control back.)
We are at cross-purposes. The processing that you describe is very much what I have running in a production framework. Its just that the parts are moved around as a response to the "fundamental law"; there cannot be any "operator>>".
I don't care much how it's labeled, or how it fits into anybody's Grand Unified Theory of I/O. I just want to be able to plumb a nonblocking socket to code that only knows how to talk to a bog-standard istream or an ostream, and have reason to expect it
One day the name might be interesting, i.e. not today:-) An istream (i.e. specifically operator>>) blocks the calling thread until the object is complete. Application code in "truly async" software can never be blocked. I use quotes for "truly async" to acknowledge that its just a label for a certain category of software (e.g. telephony signaling systems). There are other categories. The code you want to plumb to a non-blocking socket is in one of those other categories. Cheers.