Hi Boris, ----- Original Message ----- From: "Boris" <boris@gtemail.net> To: <boost@lists.boost.org> Sent: Wednesday, April 27, 2005 9:47 PM Subject: [boost] Re: Re: Re: Re: Re: (Another) socket streams library
Scott Woods wrote:
[...] Yeah, tricky stuff. After several attempts with varying levels of success the following is the most complete and efficient that I have come up with. This is specifically to deal with "streaming" over async sockets. This may ramble a bit but hopefully with purpose :-)
If I understand correctly your socket streams support blocking I/O. However I/O methods are guaranteed to return immediately as data is copied to the so-called "application zone" where it waits until it is sent to the network?
Yes to the first question (i.e. blocking I/O). Not clear on what you were asking in the second. I'll try the shotgun approach and hope I hit something :-) Streaming operations might be characterized as "application-object-centric" (and rightly so!). Operations in the "application zone" involve the sending of application objects to a "stream". Async I/O operations might be characterized as "network-event-centric". Code responding to network notifications (e.g. ready-to-send) is focused on making as much of the opportunity as possible (e.g. present the maximum amount of data to the network API). The data flow sketched out in my previous mail, has two "buffers". The first lives between the application and network zones. The second between the "network zone" and the actual network API (e.g. ::send). Full justification for the "double buffering" is probably out of scope here; it does relate to the general need for async behaviour "intra-process". The point of presenting it at all was more about the un-coupling of streaming output operation from the actual I/O operation. Relating the streaming of an application object to a subsequent I/O error is very difficult. I specifically include the detection of such errors on "flush". After taking another approach not only has my mood improved but I now even consider the possibility that relating application streaming operation to the ultimate ::send/::write is.... wrong? My approach to input is (inevitably? ;-) completely different. There are no "operator>>( stream &, application_object & )"'s to match the output operators; the design is asymmetric. This is for the simple reason that a function with such a signature implies blocking; it must wait for potentially multiple network reads to complete the application_object. The design is fully async. Did I hit anything? Cheers.