[boost] Re: Overlapped IO usinig IOStreams library (was: re Compressionusinig IOStreams library)

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-09-11 19:49:07

"George M. Garner Jr." <gmgarner_at_[hidden]> wrote in message
news:ci01a3$a6n$1_at_sea.gmane.org...
> Johnathan,
>
>
> > Now for some real fun.  I am going to try and attach an overlapped filebuf
> > to one of your
> >> streams. :-)
> >
> > Good luck!
> >
>
> That worked without a hitch.

Great!

> But that is only because my overlapped_filebuf
> uses blocking semantics.

Yeah, I know.

> My original goal was to be able to transparently
> interchange regular files and sockets as "sinks" and this will allow me to
> do that.  But the std stream and filebuf interfaces are really a
> straight-jacket when it comes to more advanced applications, such as truly
> asynchronous io; and the sooner we realize that the better.

I agree. If you haven't already read it see 'Future Directions'
(http://tinyurl.com/6r8p2).

Forgive me if I repeat myself a bit:

My view is that to handle asynchronous i/o properly one will need to define an
AsyncronousResource concept. Using AsyncronousResources and filters one should
be able to define a number of different i/o abstractions, some of which may be
standard streams and stream buffers, but some of which may be entirely
different.

I think the crucial design question now is to make sure that current filters
will work with future AsyncronousResources, and I have tentatively concluded
that it suffices to give filters a way to indicate that fewer than the requested
number of characters have been read or written, even though EOF has not been
reached and no error has occured.

The only hard part is the return type og the member function get() for an input
filter. I suggested that it could return a class type convertible to the
character type which can be explicitly tested for eof or temporary
unavailability of data.

It would look like this:

> Imagine if, for
> example, instead of doing write(char_type*, size_t) you could do
> write(ref_string<char_type>&) or
> write(ref_string_plus_overlapped<char_type>&).  An observer could
> transparently pass the buffer to the next layer without modification while
> an asynchronous sink could take ownership of buffer by calling a swap()
> member function and then pass the buffer to a waiting thread.  The buffer
> could grow or shrink as it passes from one filter to another.  The buffer
> could even pass in round robin fashion back to its origin if every observer
> or filter called swap() in turn.  But that is just a dream.
>
> Regards,
>
> George.
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>