----- Original Message ----- From: "Nathan Myers" <ncm@cantrip.org> To: <boost@lists.boost.org> 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.