Re: [Boost-users] [asio] multiple simultaneous async_read calls

Subject: Re: [Boost-users] [asio] multiple simultaneous async_read calls
From: Lee Clagett (forum_at_[hidden])
Date: 2014-08-11 12:12:28

On Mon, Aug 11, 2014 at 9:10 AM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 11 Aug 2014 at 8:56, Lee Clagett wrote:
>
> > > I'd ask a simpler question: what use case is there for configuring
> > > multiple concurrent async reads on the same stream?
> > >
> > > On *files*, yes this makes sense. But on sockets/pipes etc, the use
> > > cases are not many (possibly with UDP yes, otherwise no).
> > >
> > If you want to queue up multiple reads at a time (data to different
> > buffers), having the framework handle it (ASIO or OS) is easier than
> > writing that portion yourself.
>
> ASIO (and AFIO) already provides scatter-gather i/o to do just this.
> Both call the appropriate OS facilities where those are available.
> See
> http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/overview/core
> /buffers.html.
>
> Niall
>

I wanted to provide a generic interface for reading from a device. The most
simple interface I can think of would be: virtual std::string read(const
std::size_t) = 0;. Also, std::istream can be used and could be preferable.
However, what if you wanted to make this interface asynchronous? I don't
think std::istream is possible, but the other interface can be: virtual
std::future<std::string> read(const std::size_t) = 0. The interface should
handle the case where a second read was done before the prior read
completed. In that situation the interface either blocks until the other
future is set or tries to have a small queue so the client can continue
working unblocked. I wanted to do the latter. Perhaps it wasn't the best
idea because it was slow (used boost::futures). Although, I had no time to
analyze the performance issues either.

There are certainly ways to achieve that asynchronous interface using
scatter gather and containers (return a future<vector<string> > or
similar), but the obvious interfaces were too messy for my liking. I became
big on NOT messing up interfaces for performance gains, I am generally
convinced that both are achievable. At the time, I thought finding a method
of queuing reads was the best way to achieve both.

Lee