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
> The diffifulties begin when you _truly_ need async input, e.g. for
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk