Boost logo

Boost :

From: Scott Woods (scottw_at_[hidden])
Date: 2005-05-08 16:31:25

Hi Nathan,

----- Original Message -----
From: "Nathan Myers" <ncm_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 06, 2005 3:16 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 )
> Ewwww, Win32.
> 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.

I had agreed with you. Determining the value of "available" is non-portable.

> > > 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.

Somewhere there is some traditional stream code that includes
calls to opertor>>. What is that code doing while you determine
when there is enough stuff?

> > > 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&.

"Examining" then.

> > > 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>>.

As I said, I am running something that has many of the parts. The
plumbing and names are different.

The standout difference is use of op>>.

> 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.

Good point.


Boost list run by bdawes at, gregod at, cpdaniel at, john at