From: Scott Woods (scottw_at_[hidden])
Date: 2005-05-01 15:50:13
----- Original Message -----
From: "Boris" <boris_at_[hidden]>
Sent: Saturday, April 30, 2005 1:30 AM
Subject: [boost] Re: Re: Re: Re: Re: Re: Re: (Another) socket streams
> > 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
> I/O by default. Instead of adding async I/O support to streams I think
> 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
> library could then provide an ACE-like package with full async I/O
> If the library user however wants to use socket streams I think his
> is based on the interface he knows. Then he has to accept that only
> I/O is supported as with other streams, too. Whoever wants to use async
> 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
> there are other reasons why a library user would like to use socket
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
I'm assuming that's accidental?
I feel as if we have clarified one thing; there can be no iostream input
over async sockets (the function signature is blocking). Which leaves the
operators and whether iostream output operators over async has any value?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk