Boost logo

Boost :

From: Scott Woods (scottw_at_[hidden])
Date: 2005-04-27 17:47:37

Hi Boris,

----- Original Message -----
From: "Boris" <boris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, April 27, 2005 9:47 PM
Subject: [boost] Re: Re: Re: Re: Re: (Another) socket streams library

> Scott Woods wrote:
> > [...]
> > Yeah, tricky stuff. After several attempts with varying levels of
> > success
> > the
> > following is the most complete and efficient that I have come up
> > with. This is specifically to deal with "streaming" over async
> > sockets. This may ramble a bit
> > but hopefully with purpose :-)
> If I understand correctly your socket streams support blocking I/O.
> I/O methods are guaranteed to return immediately as data is copied to the
> so-called "application zone" where it waits until it is sent to the

Yes to the first question (i.e. blocking I/O).

Not clear on what you were asking in the second. I'll try the shotgun
and hope I hit something :-)

Streaming operations might be characterized as "application-object-centric"
rightly so!). Operations in the "application zone" involve the sending of
objects to a "stream".

Async I/O operations might be characterized as "network-event-centric". Code
responding to network notifications (e.g. ready-to-send) is focused on
as much of the opportunity as possible (e.g. present the maximum amount of
to the network API).

The data flow sketched out in my previous mail, has two "buffers". The first
lives between the application and network zones. The second between the
zone" and the actual network API (e.g. ::send).

Full justification for the "double buffering" is probably out of scope here;
it does
relate to the general need for async behaviour "intra-process".

The point of presenting it at all was more about the un-coupling of
output operation from the actual I/O operation. Relating the streaming of an
application object to a subsequent I/O error is very difficult. I
include the detection of such errors on "flush". After taking another
not only has my mood improved but I now even consider the possibility that
relating application streaming operation to the ultimate ::send/::write
is.... wrong?

My approach to input is (inevitably? ;-) completely different. There are no
"operator>>( stream &, application_object & )"'s to match the output
operators; the design is asymmetric. This is for the simple reason that a
function with such a signature implies blocking; it must wait for
multiple network reads to complete the application_object. The design
is fully async.

Did I hit anything?


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