Re: [boost] [asio] Library Review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-27 22:30:54

Hi Ron,

--- Ronald Garcia <garcia_at_[hidden]> wrote:
> Some of the tutorial material seems too low-level with respect
> to the facilities available from the C++ Standard Library.
> Why the use of char arrays, strdup, and strlen?  Furthermore,
> is strdup a standard C++ function?  I do not think it is
> standard C.

Yep, good point. I'll change the tutorials to use things like
std::vector or std::string.

> I would like to see an interface for reading/writing that
> supports iterators if that makes sense.

I'm not sure if it does make sense, as the socket operations
must operate on contiguous sequences of bytes, which is not
something that iterators enforce.

However, it might be feasible to support iterators on containers
of POD types. For example, an overload of buffer:

  template <typename Iterator>
  unspecified buffer(Iterator begin, Iterator end);

which could be used:

  std::list<pod_type> data;
  ...
  sock.write(asio::buffer(data.begin(), data.end()));

The main problem with this approach is that it might mask
inefficiencies:

- The number of elements in the returned list of buffers cannot
  be determined until runtime, and so the return type of the
  buffer() overload would have to be something like std::vector
  or std::list.

- The number of elements might be very large, and so would
  require multiple underlying read/write system calls to
  transfer.

- The size of pod_type might be small, so it might be more
  costly to copy the list of buffers than to simply copy the POD
  values into contiguous storage (e.g. a vector) first.

- For implementations where std::vector<>::iterator is not a
  pointer it probably wouldn't be possible to optimise to use
  the already contiguous data in a single buffer.

I'm interested to know if you or others still see direct
iterator support as a useful thing to have, in light of the
above. If it is widely useful I'd be happy to add it.

> It would also be nice to be able to read from a socket into an
> std::string.  If that is possible, then it is not obvious from
> the tutorial.

The problem with std::string is that it doesn't give you write
access to an underlying buffer (as say std::vector does). This
means that a read into a string is always going to involve a
separate read into some other buffer first, and then a copy of
the data into the string.

That's not to say read support for std::string shouldn't be
added, but it would have to be as a new function (e.g.
read_string/async_read_string) rather than hooking into the
existing read functions.

> Based on the daytime tutorial, I am concerned that not enough
> high-level functionality has been added to the library.  The
> daytime examples still have the flavor of using unix sockets.
> I think that this low-level functionality is critical to
> flexibility (and perhaps performance), but I would like to be
> able to quickly construct simple network applications as well.

I'd like to see something like this layered on top of asio as a
separate framework. There are many different styles and
approaches to take, so it may actually be multiple frameworks :)

> I did not find the Timer 5 example (Using boost threads) to be
> very compelling.  Granted the examples are meant to give a
> flavor of the library interface, but it may be more compelling
> to defer multi-threading to the daytime server, perhaps
> forking a new thread on each connection.  This would probably
> more closely resemble a real use of the facility.  I suspect
> that something more would need to be done to demonstrate
> synchronization.

Fair enough, I'll have a think about a better example to
demonstrate multithreading.

> I am also curious if the library could provide synchronous
> networking (which asio supports contrary to the library's
> name) through an iostreams-like interface as well.

Yep, see the included iostreams example. I plan to tidy the
interface up a bit and make this part of the library itself.

> Demuxer: It appears that any application that uses asio must
> have one and only one demuxer object floating around.  If that
> is the case, then perhaps it would be wise to model demuxer
> after std::cout: a global object that is implicitly
> constructed and destructed and available to any translation
> unit that includes the relevant header.

Actually no, you can have multiple demuxers in a single program.
This can be used, for example, to partition a program's I/O
functionality into multiple single-threaded components.

<snip>
> 2) How can one interleave asio's demultiplexing facilities
> with other existing event-based libraries.  I'm afraid I have
> not had time to investigate whether and how this can be done
> in asio currently. But some applications will require mixing
> asio into some other master event loop. Something of like
> demuxer::run_one_event() would be a good start.

Based on other feedback, I already plan to add demuxer::run()
overloads that take a timeout indicating the maximum time that
they are allowed to execute.

<snip>
> Code Comments:
> 
> It was necessary for me to make the following changes to the
> library in order to prevent warnings and to compile under OS X
> (Panther/10.3):
<snip>

Unfortunately there are other issues with support for 10.3, such
as the lack of thread-safe DNS functions.

Cheers,
Chris