Boost logo

Boost :

From: Boris (boris_at_[hidden])
Date: 2005-03-30 16:49:40

I answer to Robert and Don in the same mail.

Don G wrote:
> [...]
> --- Robert Ramey wrote:
>> The question here is:
>> Is aio.h interface not sufficient in some way? If not, what
>> facility is it missing? If it is sufficient, then just
>> depend on the available implementation or re-implement the
>> interface in the most convenient way.

We have a bit of the same problem as with a network library built upon I/O
streams. There were many people who didn't feel comfortable with this idea
because it doesn't map well. POSIX aio supports asynchronous reading and
writing through aio_read() and aio_write(). Network developers probably
expect some kind of aio_connect() and aio_accept(), too. But these functions
do not exist as they don't make sense outside the network world. Either you
force network developers to understand how to establish and accept
connections asynchronously with the existing API (then you get a big
discussion like this one: :-)
or you extend the API for a network library. Or you propose a better
asynchronous API what Don did.

> [...]
> The first issue is what spawned to Asynchronicity thread: given a
> general async mechanism, I/O could be easily adapted to it. The
> interface could be portable, even given the diverse ways and means
> necessary to achieve the goal.

I would be happy to create a network library while concentrating on
asynchronous I/O. However I agree that it doesn't make sense if different
libraries invent some kind of asynchronicity again and again - it would be
nice to have one library for asynchronicity.

> If we are to adopt an existing interface, I believe that it should be
> general enough for non-I/O uses. It should also be something that
> could be implemented on all platforms without undue inefficiency

I agree again.

> In a previous post I showed that the async technique I am proposing
> could be (fairly<g>) easily used to shield the application from
> library worker thread issues. With a little more work (and coupling),
> the use of channel.async_call could be encapsulated/automated to
> simplify the user experience.

If I agree again I will tell you in the asynchronicity thread. :) I still
have to look at your proposal with the nexus class in detail.


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