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

From: Boris (boris_at_[hidden])
Date: 2005-04-29 08:30:44

Scott Woods wrote:
> [...]
> In certain scenarios it would be reasonable to provide "stream >> a"
> 's that block as necessary. I would like to say that those scenarious
> exist in "simple" applications but that would be too easy. And there
> is certainly value in being able to write such code in small test
> programs.
>
> The diffifulties begin when you _truly_ need async input, e.g. for
> reading
> 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 think 
there are other reasons why a library user would like to use socket streams?

Boris

> [...]