I think that : Keeping blocking io situation simple should take priority over providing non-blocking io. Alternative 1 is a non-starter. Alternative 2 is the way to go given that non-blocking filters will work without compromise in blocking situations. Keith Burton -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Turkanis Sent: 03 March 2005 04:04 To: boost@lists.boost.org Subject: [boost] [iostreams] Major interace changes planned -- commentsrequested [snip] VII. Alternatives. 1. Adopt the convention that read() always blocks until at least one character is available, and that get() always blocks. This would give up much of the advantage of non-blocking and async i/o. 2. Add new non-blocking filter concepts, but hide them in the "advanced" section of the library. All the library-provided filters would be non-blocking, and users would be encouraged, but not required, to write non-blocking filters. If you've made it this far THANK YOU!!! Please let me know your opinion. Jonathan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost