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

From: Iain K. Hanson (iain.hanson_at_[hidden])
Date: 2005-05-06 09:29:02

On Thu, 2005-05-05 at 20:16 -0700, Nathan Myers wrote:
> Scott,
> 
> 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 )
> 
> 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.
> 
Yes. this is true of many options including ioctl, fnctl and socket
options. they way to make it portable for the user is to spell them all
socket_option and let the library take care of the implementation.

/ikh

_______________________________________________________________________
This email has been scanned for all known viruses by the MessageLabs Email
Security System.
_______________________________________________________________________