Boost logo

Boost :

From: Scott Woods (scottw_at_[hidden])
Date: 2005-05-01 15:50:13


----- Original Message -----
From: "Boris" <boris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, April 30, 2005 1:30 AM
Subject: [boost] Re: Re: Re: Re: Re: Re: Re: (Another) socket streams
library

[snip]
> > of application objects off an async socket. What mechanism can we
> > use? I think its significant that there is no standard answer to
> > this. The argument over whether the blocking version should exist is
> > possibly separate to the fact that the non-blocking doesnt?
>
> I agree with what you say. However I think support for async I/O doesn't
> belong to socket streams because the stream interface doesn't support
async
> I/O by default. Instead of adding async I/O support to streams I think
async
> I/O should be provided by another package.
>

Yes. That's the "async flow" library thats been mentioned in this or
a related thread.

> If I think about a library user he might want to use async I/O. The
network
> library could then provide an ACE-like package with full async I/O
support.
> If the library user however wants to use socket streams I think his
decision
> is based on the interface he knows. Then he has to accept that only
blocking
> I/O is supported as with other streams, too. Whoever wants to use async
I/O
> has to understand how async I/O is supported anyway. But whoever wants to
> use streams probably doesn't want to learn a new interface. Or do you
think
> there are other reasons why a library user would like to use socket
streams?

Yes. The separation of async into a separate library/framework is the go.

While your comments I agree with, they read as if sync/async is a developers
choice.
I'm assuming that's accidental?

I feel as if we have clarified one thing; there can be no iostream input
operators
over async sockets (the function signature is blocking). Which leaves the
output
operators and whether iostream output operators over async has any value?

Cheers.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk