From: Scott Woods (scottw_at_[hidden])
Date: 2005-06-10 00:07:25
----- Original Message -----
From: "Caleb Epstein" <caleb.epstein_at_[hidden]>
Sent: Friday, June 10, 2005 11:10 AM
Subject: Re: [boost] [Ann] socketstream library 0.7
> Why should EWOULDBLOCK be treated as an EOF? I really think this is
> trying to fit a square peg - non-blocking sockets - into a round hole
> - iostreams.
> > > Proposed Socket Library Layers:
> > > http://thread.gmane.org/gmane.comp.lib.boost.devel/122484
> > This is more about the big picture, stacking more complex interfaces on
> > top of it. I think we should implement iostreams for sockets first, then
> > we can go on to implement the mighty httpwistream that will give you
> > "wchar_t"s, whatever the document encoding was. :-)
> I think we should implement C++ sockets first, and then iostreams on
> top of those.
> I know there have been others that have agreed with this approach
> before. Are any of them following this thread?
Dont know if I'm in that group, but certainly agree. This subject was
in a recent thread that I contributed to; I don't imagine that that was the
or that this is the last.
Having also been involved in "high speed, network-centric, message-driven
for a living" I pale at the thought of dumping the burden of iostreams on my
already busy CPUs. But that may be a response originating from or near
The fact that the programming model underlying iostreams is synchronous
to be acknowledged and that flaw is (in my opinion) untenable in a network
By the time all necessary changes are made to iostreams to allow it to
an asynchronous world, it would be seriously ugly. But that too is just my
as I have never implemented such a thing. Aint about to put my hand up
I like the two layer proposal, but I wonder at the class of applications
would be achievable within the sync iostream model; it might have a very
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk