Hi Nathan, ----- Original Message ----- From: "Nathan Myers" <ncm@cantrip.org> To: <boost@lists.boost.org> Sent: Friday, May 06, 2005 3:16 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 )
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. Cheers.