Boost logo

Boost :

From: Ronald Garcia (garcia_at_[hidden])
Date: 2005-12-29 04:19:14

To be clear, I vote YES to accept asio into Boost.

On Dec 27, 2005, at 10:30 PM, Christopher Kohlhoff wrote:

>> 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 think that the above reply relates to many of my concerns regarding
the library. A strong emphasis has been placed upon efficiency and
functionality for this library. Perhaps some of the functionality that
I mentioned (support for iterators and strings) could be added to asio
or deferred to a higher level interface. I am not sure where the line
should be drawn with respect to these pieces of functionality.
Furthermore, they only seem additive upon the design expressed in asio
as is. It is with that in mind that I vote YES to accept asio into
Boost. I do hope, however, that higher-level interfaces to the
functionality in asio are forthcoming (and I hope to have some time
soon to look for the iostreams example).

> <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.

This sounds promising. The interface I had in mind above would block
until one asynchronous event were handled (or return immediately if
none are pending). I am not sure if this is a worthwhile to have in
addition to the hard timer.

> <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.

Can 10.3 still support much of asio, or is the above a killer?


Boost list run by bdawes at, gregod at, cpdaniel at, john at