From: Scott Woods (scottw_at_[hidden])
Date: 2005-05-05 15:51:43
----- Original Message -----
From: "Nathan Myers" <ncm_at_[hidden]>
Sent: Wednesday, May 04, 2005 3:55 PM
Subject: Re: [boost] Re: (Another) socket streams library
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk