From: Nathan Myers (ncm_at_[hidden])
Date: 2005-05-05 22:16:40
On Fri, May 06, 2005 at 08:51:43AM +1200, Scott Woods wrote:
> From: "Nathan Myers" <ncm_at_[hidden]>
> > Scott:
> > > 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 )
On Linux, documented as ioctl(fd, SIOCINQ, &available) [cf. tcp(7)],
although SIOCINQ seems to be the same number as FIONREAD: 0x541B. :-)
On the BSDs it seems to be documented as FIONREAD also. Thus, not
entirely unportable; everybody seems to offer a way to get it, almost
the same way.
> > 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"?
I don't know what that means. If you're running and pawing at your
streambuf, you're not paused by any definition I know of. The notional
op>> hasn't been entered yet. You're deciding, first, whether there's
enough stuff there to merit that.
> > 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?
I prefer to say examining. (Parsing implies a grammar.) Parsing is
something our notional op>> might do after we determine that it can
run to completion without getting an EOF for EWOULDBLOCK. Does
looking for an outermost matching "}", skipping comments and string
literals, count as parsing? I don't think the answer matters. What
matters is how you can use, in your async program, library Q that
takes its input from an istream&.
> > 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>>".
If there can't be any operator>>, there's hardly any point to attaching
the socket to a streambuf at all. I seriously doubt you are running
anything like I have described. I *am* talking about calling op>>.
> > 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
> 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.
All functions "block" the calling thread until they complete, so that
definition doesn't mean anything. If you can determine that your
notional op>> won't need more bytes than are certain to be available
immediately, then it doesn't block, it executes and returns. If you
make a mistake, the system call to obtain more bytes fails, reporting
EWOULDBLOCK, your op>> sees EOF, and returns. Either way nobody has
been blocked in any meaningful sense.
I don't know from "truly async". I don't see why it was mentioned
at all, or what it has to do with this thread.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk