RE: [boost] [iostreams] Major interace changes planned -- commentsrequested

From: Keith Burton (kb_at_[hidden])
Date: 2005-03-03 04:11:15

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_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Jonathan Turkanis
Sent: 03 March 2005 04:04
To: boost_at_[hidden]
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