----- Original Message ----- From: "Boris" <boris@gtemail.net> To: <boost@lists.boost.org> 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.
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
Yes. That's the "async flow" library thats been mentioned in this or a related thread. 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.