Re: [boost] Re: (Another) socket streams library

From: Scott Woods (scottw_at_[hidden])
Date: 2005-05-05 15:51:43

Hi Nathan,

----- Original Message ----- 
From: "Nathan Myers" <ncm_at_[hidden]>
To: <boost_at_[hidden]>
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.