Re: [boost] Re: (Another) socket streams library

From: Scott Woods (scottw_at_[hidden])
Date: 2005-05-03 16:07:24

----- Original Message -----
From: "Nathan Myers" <ncm_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, May 04, 2005 6:22 AM
Subject: [boost] Re: (Another) socket streams library

[snip]
> It started me thinking about how to make an iostream useful when
> attached to a non-blocking socket.  Reading this thread, it seems
> to me you have stepped in the same trap as most other attempts.
> There are many, many libraries to make various sources and sinks,
> including sockets, look like iostreams, but without actually being
> iostreams.  We don't seem to find ourselves using them.
>
> For nonblocking socket support to be widely useful, it must be
> possible to pass such a stream to a library that takes a regular
> istream& or ostream& argument.  This has been characterized as
> impossible, because iostream semantics are not compatible with
> non-blocking I/O.  While the latter is true, the former is not.
> The key to the paradox is the expression "out-of-band".  The owner
> of the stream may know things about it, and its underlying socket,
> that the user of the istream or ostream does not, and can act
> accordingly.

Its possible you have alluded to claims of mine ("blocking signature").

If I understand your sketch; yes its certainly possibly to hide details
of async in such a way that an input call on a stream will function
in a traditional fashion.

The catch (for me) is that such a call is still blocking. The thread
that performs the call (operator<<) must wait for the complete
object off the stream.

I have seen efforts to undermine even this constraint. Setjmp+longjmp
was used in such a way that calling threads "leave" the context of an
input call and "resume" when the object was complete.

At least in my "signal processing" world (telephony) these efforts
are wasted. Objects could arrive from several sources at any
one time. At application level, i.e. "operator>>( istream &,
application_type & )",
this would mean that zero or more objects are being received between
the call and return sequence for the input operator. At the very least
this would be a difficult coding environment.

Your architecture (IIUC?) looks fine to me. As you mention there
is a large category of problems that it solves. I just wouldnt characterize
it as async.

Or have I mis-fired?

Cheers.