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
[...]