[boost] Re: Asynchronous I/O

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: 
http://lists.freebsd.org/pipermail/freebsd-net/2004-October/005307.html :-) 
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.

Boris