[boost] Re: Asynchronicity (long)

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-04-01 21:15:49

Boris wrote:
> Edward Diener wrote:
>> [...]
>>> 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.
>
> Maybe I didn't explain myself very good because I also like how .NET
> supports asynchronous operations. :) If I take the socket class in
> .NET as
> an example: You could call Socket.Connect() asynchronously like any
> other function using a delegate. However the socket class supports
> asynchronous
> I/O explicitly providing a BeginConnect() and EndConnect() method
> which is more efficiently implemented. However there is an
> asynchronous design
> pattern in .NET so whoever designed BeginConnect() and EndConnect()
> had to follow some rules.
>
> As far as I understand you agree that we should do in C++ similarly?

Similarly, but using the facilities of modern C++. There is no need to
exactly emulate .NET's design when C++ provides a possibly richer way of
doing things.

> There should be an asynchronicity library based on threads and
> callbacks (and
> maybe some other features).

Agreed. A separate asynchronous library which has nothing to do with I/O per
se but rather defines a model for doing callbacks in threads which can be
invoked asynchronously.

> Then we have a network library supporting
> different models of I/O including asynchronous I/O.

The reason I posited a separate library for purely asynchronous I/O, rather
than folding that into the network library, is that there are models in
which an asynchronous I/O library may have nothing to do with network
access. For instance it is possible in some operating systems to read/write
files asynchronously. Should this come under the aegis of a network library
? I do not think so since the file I/O will normally occur locally. On the
other hand, remote access to files may be thought of as network
functionality and it may be possible to do file I/O remotely asynchronously.
So my point was simply that an asynchronous I/O model may be something that
can be used by more than just a network library and may be considered
separately.

> The asynchronous
> support will be explicitly provided by the network library. The
> library user doesn't need to use the asynchronicity library himself
> to do asynchronous I/O as there will be explicit support just like in
> .NET. How this explicit support of asynchronous I/O is implemented
> doesn't matter.

Agreed.

>
> If we agree upon this we need an asynchronous design pattern in C++,
> too. Asynchronous I/O support in a network library must be then
> designed
> according to this pattern. And of course any other library which will
> support asynchronous operations explicitly have to follow this design
> pattern, too.

That is the idea. If the pattern is flexible enough, an asynchronous I/O
library could be useful outside of what is thought of as networking
operations. It all depends on what is considered "network programming" and
what is not. If I send data through a USB port to read/write from/to a
hardare device, is that "network programming" ? Probably not, but a good
asynchronous I/O model might be built that can be used in that situation
also.

C++ currently has a standard I/O library. Many people may not like it
because of its complexity but it was designed to be broadly applied and to
be flexible for many forms of I/O. Unfortunately it is purely synchronous,
mainly because the idea of asynchronicity was considered outside the sope of
the standard C++ libraries and outside the scope of the language itself, not
to speak also of the idea of threading.

In the same way a general purpose asynchronous I/O library could serve the
same purpose as the standard C++ "synchronous" I/O library.

>
>>> 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.
>
> Until now I was thinking about an asynchronicity library and a network
> library. You think about putting another library in between - an
> asynchronous I/O library?

Yes, see argument above. The main reason for my argument is reuse by other
libraries doing asynchronous I/O but which may not be network related. If
the network library is going to support asynchronous operations, which is
only natural because of the time it takes for things to happen over
networks, other libraries not defined as "network" but still wanting to
offer asynchronous I/O operations could use a general purpose asynchronous
I/O library to achieve their ends also.

Of course all this is theoretical design. It may be that the ideas of a
separate asynchronous library, asynchronous I/O library, and network library
are unrealistic and one can not separate these things as cleanly as I would
believe, but I still think the idea of having these libraries for re-use is
the right one.

Even just a separate asynchronous library could be used when not doing I/O
but just wanting to provide asynchronous "background" operations for
processes which have to be responsive to end-user input.

Of course separate asynchronous libraries and asynchronous I/O libraries
exist in C++ but their models appear to me to be essentially C procedural
programming models. Modern C++ should be able to come up with things that
are more robust and take advantage of possibly both OOP programming and
generic programming knowledge.

Eddie