[boost] Re: Asynchronicity (long)

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-04-01 14:48:34

Boris wrote:
> Edward Diener wrote:
>> Boris wrote:
>> [...]
>>> While asynchronicity in .NET is basically based on threads it is not
>>> true
>>> for asynchronous I/O. If you built asynchronous I/O on top of an
>>> asynchronicity library with callbacks in threads you will end up
>>> with 1000 threads blocked in read() if you have 1000 sockets.
>>
>> 1) No one normally uses 1000 sockets. Be real rather than hyperbolic
>> if you are trying to make a point.
>
> I don't know why a C++ network library shouldn't be able to do what
> eg. is possible in .NET.
>
>> 2) Any good asynchronous I/O library should be able to callback on
>> the same thread or another thread.
>
> No problem with that.
>
>> 3) If I am doing socket programming I often do not want to hold up my
>> main thread by having callbacks in it.
>
> Yes, there are various possibilities to support asynchronous I/O
> although callbacks seem to be most asynchronous. :)
>
>>> This doesn't
>>> happen in .NET and I don't think anyone want this to happen in a C++
>>> network library. As an asynchronicity library doesn't know if a
>>> blocking function does I/O it will always call this function in a
>>> thread.
>>
>> Good. If you are using an asynchronous library, it means by its very
>> nature that you want to perform your action in another thread, so
>> that your current thread can continue. Whether it is blocking waiting
>> on I/O or not is irrelevant. That is up to the programmer to know,
>
> Okay.
>
>> not the library. If it is not blocking the new thread will handle it
>> quickly and exit. Worrying about creating threads is thinking about
>> performance instead of design. No matter what anyone says, design
>> well first and deal with performance later.
>
> Considering the bad support of asynchronous I/O on different operating
> systems I disagree that we should ignore the performance impacts of
> design decisions.
>
>>> The network library however
>>> knows better and can provide a much more efficient implementation of
>>> asynchronous I/O than an asynchronicity library can do.
>>
>> You are trying to tie a network library to an asynchronous library,
>
> No, I don't want to do this. It is perfectly okay to have a
> stand-alone asynchronicity library. I am trying to find out if a
> network library should make use of such a stand-alone asynchronicity
> library or if the network library should deal with asynchronous I/O
> itself.

In .NET, asychronous calls have their own general interface. When the
programmer uses, as an example, a socket he/she may choose to call a number
of functions either synchronously or asynchronously, with the asynchronous
calls using the same general interface as the rest of asynchronous calls in
.NET.

In the same way if Boost has an asynchronous I/O library built around
threads and callbacks, a separate Boost network library should offer both
synchronous or asynchronous functionality to the end-programmer. In offering
asynchronous functionality the network library can use the asynchronous I/O
library to make asynchronous calls. The good thing about this decoupling is
that another completely different Boost library, for example a file I/O
libary, should be able to use the general purpose asynchronous I/O library
for its own purposes also. I am only arguing generally for an asynchronous
I/O library built around what already exists in Boost from Boost threads and
Boost function ( for callbacks ).

>
>> and so you are confusing two issues.. Decouple them instead. An
>> asynchronous
>> library could be modelled around the suggestion I made, and your
>> network library could decide to use its asynchronous I/O facilities
>> depending on
>> what it wants to do.
>
> But how does the network library provide asynchronous I/O operations
> to the library user?

That is up to the network library designer/implementer but I see no reason
why the network library can not provide both synchronous and asynchronous
functionality in a number of areas. This is very similar to the way that
sockets, as an example, works in .NET, where one can call certain
functionality either synchronously, waiting for the call to finish, or
asynchronously, returning to do other things while the call will finish when
a delegate on another thread is invoked.

> If you tell me that's up to the network library
> asynchronous I/O provided by the network library will be used
> differently than what eg.
> an asynchronicity library might provide.

The challenge of an asynchronous I/O library is to provide a general enough
interface to allow other more specific libraries to use it for their own
specific asynchronous I/O purposes, else there is little purpose in creating
it.

> And I am only talking about
> the interface not about the implementation. The nice thing in .NET is
> that asynchronous operations look everywhere the same no matter if
> you are in the network library or somewhere else.

I agree, looking very much the same but allowing both the end-programmer,
and the particularly implementation of asynchronous callback functionality,
to pass different data to an asynchronous callback, and also using the
results of data picked up by the callback in different ways depending on the
implementation.

I think we are mostly agreeing. My original appeal is that building a
general purpose asynchronous I/O library around Boost threads and Boost
function seems feasible, since the equivalent concepts have already been
shown to work in another environment, and might save a great deal of trouble
from trying to re-invent the code from scratch all over again. On top of
that general purpose asynchronous I/O library other implementors which need
asynchronous I/O in their particular libraries can build whatever elaborate
schemes they want.

Perhaps "asynchronous I/O" is a bad name and one should just settle for an
"asynchronous calls" library, although the I/O portion of it may incorporate
general ideas of how to do I/O, perhaps using streams ala the I/O streams
library but with the idea that a particular streaming operation may block
waiting for input or output to complete. So the breakdown of the problem,
from a network library point of view, could be:

1) A general purpose asynchronous callback library.
2) A general purpose asynchronous I/O library using 1) and considering how
I/O should be implemented.
3) A network library, or any other library which might want to make
asynchronous I/O calls, using 2).

Usually when a problem is complex it is much easier breaking it down into
manageable pieces, and makes for more resuable programming. That is why
Boost is so great, since it offers many great pieces which one can use to
build even more complicated things.